From rfid-bounces@lists.ietf.org Tue Jul 05 01:52:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpgLj-00063N-7E; Tue, 05 Jul 2005 01:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpgLh-000637-5Y for rfid@megatron.ietf.org; Tue, 05 Jul 2005 01:52:01 -0400 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25743 for ; Tue, 5 Jul 2005 01:52:00 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id i31so806217wra for ; Mon, 04 Jul 2005 22:51:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Gk9E2yArLFupo0gZU4rr7kwCO80qh4KMSb+9A1lRWnL3hD45qcFk1soJSroGodAgx5iWqQ83Cndi9JrTJBI0yDv8F8ipCzC1r8+dFQMMzouN2EIQe+XQemKY8nSpLdU3NtUslAVuk1ugTSsOU3OEg6moseVEmpEHka0r12e61f8= Received: by 10.54.26.45 with SMTP id 45mr4272935wrz; Mon, 04 Jul 2005 22:51:29 -0700 (PDT) Received: by 10.54.83.4 with HTTP; Mon, 4 Jul 2005 22:51:29 -0700 (PDT) Message-ID: <3e7aae3050704225157a4aeae@mail.gmail.com> Date: Tue, 5 Jul 2005 11:21:29 +0530 From: Ramya Desai To: rfid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [Rfid] Free source code for EPC RFID X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ramya Desai List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Dear all, Does any one of you know that if any free software available for RFID proto= col. If any one know I request you to please forward me the links or code. Thanks and regards, Ramya _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Jul 05 03:28:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dphqp-0006XI-3i; Tue, 05 Jul 2005 03:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dphqn-0006Vr-CQ for rfid@megatron.ietf.org; Tue, 05 Jul 2005 03:28:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07734 for ; Tue, 5 Jul 2005 03:28:11 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpiHU-000200-PR for rfid@ietf.org; Tue, 05 Jul 2005 03:55:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 2F05C26C090; Tue, 5 Jul 2005 09:27:59 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 13EA826C072; Tue, 5 Jul 2005 09:27:57 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j657RuuT975698; Tue, 5 Jul 2005 09:27:57 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id DDE1616AA81; Tue, 5 Jul 2005 09:27:56 +0200 (CEST) Date: Tue, 5 Jul 2005 09:27:56 +0200 From: Stephane Bortzmeyer To: Ramya Desai Message-ID: <20050705072756.GA18894@nic.fr> References: <3e7aae3050704225157a4aeae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e7aae3050704225157a4aeae@mail.gmail.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rfid@ietf.org Subject: [Rfid] Re: Free source code for EPC RFID X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org [Warning: unless I misunderstood the chart, this working group does not work on the air protocol - between a tag and a reader - but on the protocol to query / set / etc the readers from a managing host.] On Tue, Jul 05, 2005 at 11:21:29AM +0530, Ramya Desai wrote a message of 12 lines which said: > Does any one of you know that if any free software available for > RFID protocol. http://rfid.objectweb.org/rfid-list.html will give you links to all of them. _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Jul 05 08:50:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpmsr-0001Cq-78; Tue, 05 Jul 2005 08:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpmsn-0001CQ-Ga for rfid@megatron.ietf.org; Tue, 05 Jul 2005 08:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26024 for ; Tue, 5 Jul 2005 08:50:34 -0400 (EDT) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpmRO-0008OY-3x for rfid@ietf.org; Tue, 05 Jul 2005 08:22:19 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 07:54:09 -0400 Subject: Re: [Rfid] Re: Free source code for EPC RFID From: Scott Barvick To: Stephane Bortzmeyer In-Reply-To: <20050705072756.GA18894@nic.fr> References: <3e7aae3050704225157a4aeae@mail.gmail.com> <20050705072756.GA18894@nic.fr> Content-Type: text/plain Message-Id: <1120564448.2386.11.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 05 Jul 2005 07:54:09 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 11:54:09.0748 (UTC) FILETIME=[40FEE940:01C58158] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Stephane, You are correct that this list is for the development of a 'network side' protocol that works between the reader and a controller (and not the air protocol). There is an open source project associated with the development of this protocol as a standard as well - see http://slrrp.sourceforge.net. Scott On Tue, 2005-07-05 at 03:27, Stephane Bortzmeyer wrote: > [Warning: unless I misunderstood the chart, this working group does > not work on the air protocol - between a tag and a reader - but on the > protocol to query / set / etc the readers from a managing host.] > > On Tue, Jul 05, 2005 at 11:21:29AM +0530, > Ramya Desai wrote > a message of 12 lines which said: > > > Does any one of you know that if any free software available for > > RFID protocol. > > http://rfid.objectweb.org/rfid-list.html > > will give you links to all of them. > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Mon Jul 18 09:14:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVRg-0007R2-5v; Mon, 18 Jul 2005 09:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVRd-0007Qq-UI for rfid@megatron.ietf.org; Mon, 18 Jul 2005 09:14:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09323 for ; Mon, 18 Jul 2005 09:14:04 -0400 (EDT) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuVv2-0007vY-Hk for rfid@ietf.org; Mon, 18 Jul 2005 09:44:30 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 09:13:31 -0400 From: Scott Barvick To: rfid@ietf.org Content-Type: text/plain Message-Id: <1121692410.2616.64.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Jul 2005 09:13:30 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 13:13:31.0212 (UTC) FILETIME=[7E6B68C0:01C58B9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Subject: [Rfid] Version numbering X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org As I hear of more implementations of SLRRP starting to happen, it seems that we need to decide what we put in the version field while the spec is still an I-D. To date, we've just been specifying the draft number as the version, and that is what is in the SourceForge code, but that doesn't seem like the way to continue, especially when we have only allocated 3 bits to it. One proposal would be to just use '0' for all pre-standard versions and not try to match up functionality with version numbering any more granularly than that. Another approach would be to take another bit for the version, but that seems like overkill given the well understood extensibility mechanisms that allow for the protocol to grow without requiring the version to change. We could also start with 0 but all decide that a more significant change in the draft would cause us to go to 1 even if we are still in draft state. We could then rev it again as we take it toward a standard. We wouldn't necessarily bump it for each draft, but basically we'd be accepting the fact that a bump in version number was necessary for the set of implementations out there, and that our initial version number in a standard might just be greater than 1. Other thoughts? Scott _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Mon Jul 18 09:59:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuW9M-0001Of-PO; Mon, 18 Jul 2005 09:59:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuW4D-0000N1-1f for rfid@megatron.ietf.org; Mon, 18 Jul 2005 09:53:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11818 for ; Mon, 18 Jul 2005 09:53:55 -0400 (EDT) Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuWXd-00023I-By for rfid@ietf.org; Mon, 18 Jul 2005 10:24:22 -0400 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id j6IDpWrX005133; Mon, 18 Jul 2005 06:51:33 -0700 In-Reply-To: <1121692410.2616.64.camel@saco.revasystems.com> References: <1121692410.2616.64.camel@saco.revasystems.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [Rfid] Version numbering Date: Mon, 18 Jul 2005 19:23:35 +0530 To: Scott Barvick X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Jul 2005 09:59:14 -0400 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org On Jul 18, 2005, at 18:43 , Scott Barvick wrote: > One proposal would be to just use '0' for all pre-standard versions > and > not try to match up functionality with version numbering any more > granularly than that. that is the best choice. all versions of a protocol prior to RFC publication are equally obsolete. /mtr _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Mon Jul 18 10:19:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWKa-0004YV-Hf; Mon, 18 Jul 2005 10:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWKY-0004YA-D1 for rfid@megatron.ietf.org; Mon, 18 Jul 2005 10:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13475 for ; Mon, 18 Jul 2005 10:10:48 -0400 (EDT) Received: from web312.biz.mail.mud.yahoo.com ([68.142.199.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuWnx-0003C6-C8 for rfid@ietf.org; Mon, 18 Jul 2005 10:41:15 -0400 Received: (qmail 87396 invoked by uid 60001); 18 Jul 2005 14:10:32 -0000 Message-ID: <20050718141032.87394.qmail@web312.biz.mail.mud.yahoo.com> Received: from [209.6.248.193] by web312.biz.mail.mud.yahoo.com via HTTP; Mon, 18 Jul 2005 07:10:31 PDT Date: Mon, 18 Jul 2005 07:10:31 -0700 (PDT) From: Bud Biswas Subject: Re: [Rfid] Version numbering To: Scott Barvick , rfid@ietf.org In-Reply-To: <1121692410.2616.64.camel@saco.revasystems.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bbiswas@polarisnetworks.net List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0533839098==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org --===============0533839098== Content-Type: multipart/alternative; boundary="0-1655367685-1121695831=:84648" Content-Transfer-Encoding: 8bit --0-1655367685-1121695831=:84648 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Scott: I would like to see the current version as 0 as opposed to draft number (I think Reva is using the draft number at this point for version field) and let's consider that current draft (.02) is the version 0. Implementors should remember that current draft has a different header structure compared to older drafts. That means draft 0 will not interoperate with draft 2. I had some problems in interoperating with draft 0 and draft 2 implementations. Thanks. Bud Biswas Scott Barvick wrote: As I hear of more implementations of SLRRP starting to happen, it seems that we need to decide what we put in the version field while the spec is still an I-D. To date, we've just been specifying the draft number as the version, and that is what is in the SourceForge code, but that doesn't seem like the way to continue, especially when we have only allocated 3 bits to it. One proposal would be to just use '0' for all pre-standard versions and not try to match up functionality with version numbering any more granularly than that. Another approach would be to take another bit for the version, but that seems like overkill given the well understood extensibility mechanisms that allow for the protocol to grow without requiring the version to change. We could also start with 0 but all decide that a more significant change in the draft would cause us to go to 1 even if we are still in draft state. We could then rev it again as we take it toward a standard. We wouldn't necessarily bump it for each draft, but basically we'd be accepting the fact that a bump in version number was necessary for the set of implementations out there, and that our initial version number in a standard might just be greater than 1. Other thoughts? Scott _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid Polaris Networks your source for rfid test tools --0-1655367685-1121695831=:84648 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Scott:
 
I would like to see the current version as 0 as opposed to draft number (I think Reva is using the draft number at this point for version field) and let's consider that current draft (.02) is the version 0. Implementors should remember that current draft has a different header structure compared to older drafts. That means draft 0 will not interoperate with draft 2. I had some problems in interoperating with draft 0 and draft 2 implementations.
 
Thanks.
 
Bud Biswas

Scott Barvick <sbarvick@revasystems.com> wrote:

As I hear of more implementations of SLRRP starting to happen, it seems
that we need to decide what we put in the version field while the spec
is still an I-D.

To date, we've just been specifying the draft number as the version, and
that is what is in the SourceForge code, but that doesn't seem like the
way to continue, especially when we have only allocated 3 bits to it.

One proposal would be to just use '0' for all pre-standard versions and
not try to match up functionality with version numbering any more
granularly than that.

Another approach would be to take another bit for the version, but that
seems like overkill given the well understood extensibility mechanisms
that allow for the protocol to grow without requiring the version to
change.

We could also start with 0 but all decide that a more significant chang! e
in the draft would cause us to go to 1 even if we are still in draft
state. We could then rev it again as we take it toward a standard. We
wouldn't necessarily bump it for each draft, but basically we'd be
accepting the fact that a bump in version number was necessary for the
set of implementations out there, and that our initial version number in
a standard might just be greater than 1.

Other thoughts?


Scott


_______________________________________________
Rfid mailing list
Rfid@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid


Polaris Networks
your source for rfid test tools
--0-1655367685-1121695831=:84648-- --===============0533839098== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0533839098==-- From rfid-bounces@lists.ietf.org Tue Jul 19 08:28:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurDE-0007KP-KW; Tue, 19 Jul 2005 08:28:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dur95-0006M1-3K for rfid@megatron.ietf.org; Tue, 19 Jul 2005 08:24:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08379 for ; Tue, 19 Jul 2005 08:24:21 -0400 (EDT) Received: from web306.biz.mail.mud.yahoo.com ([68.142.199.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Durcb-0004TC-RD for rfid@ietf.org; Tue, 19 Jul 2005 08:55:00 -0400 Received: (qmail 57494 invoked by uid 60001); 19 Jul 2005 12:24:07 -0000 Message-ID: <20050719122407.57492.qmail@web306.biz.mail.mud.yahoo.com> Received: from [61.11.91.132] by web306.biz.mail.mud.yahoo.com via HTTP; Tue, 19 Jul 2005 13:24:07 BST Date: Tue, 19 Jul 2005 13:24:07 +0100 (BST) From: Sudip Chandra To: rfid@ietf.org In-Reply-To: <20050719121022.69615.qmail@web303.biz.mail.mud.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Tue, 19 Jul 2005 08:28:38 -0400 Cc: Subject: [Rfid] SLRRP Missing Parameters X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682446230==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org --===============1682446230== Content-Type: multipart/alternative; boundary="0-954580485-1121775847=:56544" Content-Transfer-Encoding: 8bit --0-954580485-1121775847=:56544 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear Sir, I am Senior Engineer at Polaris Networks Inc working in SLRRP Protocol Decoder.While working in SLRRP Packet Decoder ,I am not getting definitions of parametrs namely packet structure Inventory and Access Data Parameter , Access Report Data Parameter, RF Report Data Parameter ,Reader_Status_Report and Statistics Parameter in INVENTORY_ACCESS_REPORT .Can someone help in getting these Parameter definitions ? Thanks and regards, Sudip --0-954580485-1121775847=:56544 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Dear Sir,

I am Senior Engineer at Polaris Networks Inc working in SLRRP Protocol Decoder.While working in SLRRP Packet Decoder ,I am not getting definitions of  parametrs namely packet structure Inventory and Access Data Parameter , Access Report Data Parameter, RF Report Data Parameter ,Reader_Status_Report  and Statistics Parameter in INVENTORY_ACCESS_REPORT .Can someone help in getting these Parameter definitions ?

Thanks and regards,

Sudip

 

--0-954580485-1121775847=:56544-- --===============1682446230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1682446230==-- From rfid-bounces@lists.ietf.org Tue Jul 19 08:42:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurQy-0003CA-GP; Tue, 19 Jul 2005 08:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DurQu-0003C5-4q for rfid@megatron.ietf.org; Tue, 19 Jul 2005 08:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09528 for ; Tue, 19 Jul 2005 08:42:44 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuruU-00057G-DX for rfid@ietf.org; Tue, 19 Jul 2005 09:13:23 -0400 Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 08:42:26 -0400 Subject: Re: [Rfid] SLRRP Missing Parameters From: "P. Krishna" To: Sudip Chandra In-Reply-To: <20050719122407.57492.qmail@web306.biz.mail.mud.yahoo.com> References: <20050719122407.57492.qmail@web306.biz.mail.mud.yahoo.com> Content-Type: text/plain Message-Id: <1121776945.28648.4667.camel@indus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 19 Jul 2005 08:42:26 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2005 12:42:26.0982 (UTC) FILETIME=[51AA3C60:01C58C5F] X-Spam-Score: 1.2 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Sudip, Thats because, these parameters have not been defined in the spec yet. We are working on completing those definitions. Thanks, /Krishna On Tue, 2005-07-19 at 08:24, Sudip Chandra wrote: > Dear Sir, > > I am Senior Engineer at Polaris Networks Inc working in SLRRP Protocol > Decoder.While working in SLRRP Packet Decoder ,I am not getting > definitions of parametrs namely packet structure Inventory and Access > Data Parameter , Access Report Data Parameter, RF Report Data > Parameter ,Reader_Status_Report and Statistics Parameter in > INVENTORY_ACCESS_REPORT .Can someone help in getting these > Parameter definitions ? > > Thanks and regards, > > Sudip > > > > > > ______________________________________________________________________ > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Jul 19 10:34:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutAv-0003uV-Oz; Tue, 19 Jul 2005 10:34:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutAt-0003uQ-6E for rfid@megatron.ietf.org; Tue, 19 Jul 2005 10:34:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18930 for ; Tue, 19 Jul 2005 10:34:20 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuteV-0001LE-OE for rfid@ietf.org; Tue, 19 Jul 2005 11:05:01 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 10:34:10 -0400 Subject: Re: [Rfid] SLRRP Missing Parameters From: Scott Barvick To: "P. Krishna" In-Reply-To: <1121776945.28648.4667.camel@indus> References: <20050719122407.57492.qmail@web306.biz.mail.mud.yahoo.com> <1121776945.28648.4667.camel@indus> Content-Type: text/plain Message-Id: <1121783649.2616.462.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 19 Jul 2005 10:34:09 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2005 14:34:10.0493 (UTC) FILETIME=[ED44D6D0:01C58C6E] X-Spam-Score: 1.2 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org, Sudip Chandra X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org And 'we' should be taken to mean the community at large. As we start to get more members, more interest, more implementations I want to make sure folks know that submissions for missing functionality, bugs, etc are welcome from all. Submissions should be posted for review and discussion, and an editor will incorporate the consensus into later revs of the draft. On that note, I would like to make sure that the folks new to the IETF and/or the list are aware of the IETF's intellectual property policy. It can be found at: https://datatracker.ietf.org/public/ipr_disclosure.cgi Contributions to this list should be considered to fall under this policy. Also, there are others with more experience in the letter and spirit on the list in case there any questions. Thanks, Scott On Tue, 2005-07-19 at 08:42, P. Krishna wrote: > Sudip, > Thats because, these parameters have not been defined in the spec yet. > We are working on completing those definitions. > > Thanks, > /Krishna > On Tue, 2005-07-19 at 08:24, Sudip Chandra wrote: > > Dear Sir, > > > > I am Senior Engineer at Polaris Networks Inc working in SLRRP Protocol > > Decoder.While working in SLRRP Packet Decoder ,I am not getting > > definitions of parametrs namely packet structure Inventory and Access > > Data Parameter , Access Report Data Parameter, RF Report Data > > Parameter ,Reader_Status_Report and Statistics Parameter in > > INVENTORY_ACCESS_REPORT .Can someone help in getting these > > Parameter definitions ? > > > > Thanks and regards, > > > > Sudip > > > > > > > > > > > > ______________________________________________________________________ > > _______________________________________________ > > Rfid mailing list > > Rfid@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/rfid > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Wed Jul 20 18:44:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNIP-0000GE-Hm; Wed, 20 Jul 2005 18:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvNIN-0000Fg-U2 for rfid@megatron.ietf.org; Wed, 20 Jul 2005 18:44:08 -0400 Received: from charles.revasystems.com (charles.revasystems.com [65.209.89.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05312 for ; Wed, 20 Jul 2005 18:44:04 -0400 (EDT) Received: from [192.168.1.50] (avon [192.168.1.50]) by charles.revasystems.com (Postfix) with ESMTP id 2CAE53BE90 for ; Wed, 20 Jul 2005 18:43:36 -0400 (EDT) From: Peter Spreadborough To: rfid@ietf.org Content-Type: text/plain Message-Id: <1121899416.21285.235.camel@mad> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 20 Jul 2005 18:43:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Rfid] SLRRP Vendor Extensions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org To facilitate the support of vendor specific extensions, prior to formal inclusion into the protocol, the following solution is proposed: 1. The SLRRP message header will be extended to include a thirty two bit vendor ID field: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x| Ver | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |x x x x x x x x x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Message Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. For SLRRP parameters a bit from the "user" bits will be assigned as the Vendor or V bit. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |V|User | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Parameter Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. A block of unused message types will be reserved for vendor extensions. 4. A block of parameter types will be reserved for vendor extensions. SLRRP implementations may choose to ignore: - Any message types that fall in to the vendor extension range. - Any parameter types that fall into the vendor extension range. - Any parameters that have the V bit set. If the V bit is set in a parameter header then the vendor ID used in the encapsulating message will apply. The parameter may then be accepted or ignored based on the vendor ID. This applies to both defined message types and extended message types. _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Wed Jul 20 20:57:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPNU-00061I-QW; Wed, 20 Jul 2005 20:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPNT-000619-FS for rfid@megatron.ietf.org; Wed, 20 Jul 2005 20:57:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20606 for ; Wed, 20 Jul 2005 20:57:29 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvPrL-0002QU-Iv for rfid@ietf.org; Wed, 20 Jul 2005 21:28:27 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 446180; Wed, 20 Jul 2005 20:51:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1121899416.21285.235.camel@mad> References: <1121899416.21285.235.camel@mad> Date: Wed, 20 Jul 2005 20:55:45 -0400 To: Peter Spreadborough , rfid@ietf.org From: Margaret Wasserman Subject: Re: [Rfid] SLRRP Vendor Extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi Peter, Before deciding to add a vendor extensions mechanism to SLRRP, it might be useful to read the IESG document regarding vendor extensions: http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-02.txt This document is not a mandate against all forms of vendor extension, but it does make a good case that the use of vendor extensions should be extremely limited, as uncontrolled vendor extension mechanisms (such as the one you have described) tend to lead to incompatibility between different devices that can correctly claim to implement the same protocol. If the group decides that vendor extensions are necessary, then it might be preferable to simply set aside a portion of the message type and parameter type values for IANA assignment with an appropriate level of documentation and/or review (as described in RFC 2434). Margaret At 6:43 PM -0400 7/20/05, Peter Spreadborough wrote: >To facilitate the support of vendor specific extensions, prior to formal >inclusion into the protocol, the following solution is proposed: > >1. The SLRRP message header will be extended to include a thirty two bit >vendor ID field: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x| Ver | Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Seq Num |x x x x x x x x x x x x x x x x| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor ID | >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : Message Value : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >2. For SLRRP parameters a bit from the "user" bits will be assigned as >the Vendor or V bit. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | A |V|User | Parameter Type | Parameter Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : Parameter Value : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >3. A block of unused message types will be reserved for vendor >extensions. >4. A block of parameter types will be reserved for vendor extensions. > >SLRRP implementations may choose to ignore: > - Any message types that fall in to the vendor extension range. > - Any parameter types that fall into the vendor extension range. > - Any parameters that have the V bit set. > >If the V bit is set in a parameter header then the vendor ID used in the >encapsulating message will apply. The parameter may then be accepted or >ignored based on the vendor ID. This applies to both defined message >types and extended message types. > > > > >_______________________________________________ >Rfid mailing list >Rfid@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Wed Jul 20 21:06:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPWC-0001lx-AZ; Wed, 20 Jul 2005 21:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPWB-0001ls-As for rfid@megatron.ietf.org; Wed, 20 Jul 2005 21:06:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21264 for ; Wed, 20 Jul 2005 21:06:29 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQ07-00030E-Mc for rfid@ietf.org; Wed, 20 Jul 2005 21:37:27 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 446182 for rfid@ietf.org; Wed, 20 Jul 2005 21:00:26 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 20 Jul 2005 21:05:12 -0400 To: rfid@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.7 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Rfid] SLRRP -> RRCP? X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi All, I was talking to Scott Barvick off-line, and I made a comment that is probably better shared with the list... To avoid later pain/confusion, I think it would be preferable to change the name of the SLRRP protocol to something that doesn't contain "marketing" terms like "Simple" or "Lightweight". The IESG will not generally approve documents that include those words in the title or document name, as they are seen as marketing terms, not engineering terms. I recently encountered this issue with an IPDVB WG protocol. See the comments from David Kessens at: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11634&rfc_flag=0 We were forced to rename the ULE protocol in the final stages, which was a bit painful. Fortunately, we found a reasonable name that retained the commonly-used ULE acronym, or it would have been worse. Given that David is one of the area directors for this effort, I doubt that we can slip a protocol past him that claims to be both "simple" and "lightweight". In the interest of avoiding that problem if/when this group becomes a WG and wants to publish a SLRRP-inspired protocol, I'd suggest that we rename the protocol now, while it will have less impact on the effort. How about "RFID Reader Control Protocol (RRCP)"? It's not as easily pronounced, but it is more descriptive. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Wed Jul 20 22:19:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQf9-0006Rj-Rh; Wed, 20 Jul 2005 22:19:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvQf6-0006MZ-SG for rfid@megatron.ietf.org; Wed, 20 Jul 2005 22:19:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29693 for ; Wed, 20 Jul 2005 22:19:46 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvR90-00005I-DZ for rfid@ietf.org; Wed, 20 Jul 2005 22:50:45 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 446258 for rfid@ietf.org; Wed, 20 Jul 2005 22:13:31 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 20 Jul 2005 22:19:17 -0400 To: rfid@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Subject: [Rfid] XML vs. Text vs. Binary X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org We've had some discussion on this list about XML encoding vs. binary encoding... I'm not sure that we are in agreement on all of the related points, but the concerns with XML seem to be code size on the reader and protocol overhead on the wire. These concerns can be minimized by the use of a restricted XML subset, such as canonical XML (see RFC 3076). However, there still seem to be some concerns along those lines. The only advantages that I remember being discussed for a binary encoding were the complement to the concerns with XML: smaller code size on the reader and less protocol overhead. I think, though, that our discussions have missed a major benefit of any text-based encoding (whether a protocol-specific text encoding or canonical XML): the ability to access the device using text processing tools (such as Perl scripts) and/or for a human to interact with the device directly. In 2002, the IAB held a Network Management workshop that is documented in RFC 3535. I would suggest that folks on this list read this report which can be found at: http://www.ietf.org/rfc/rfc3535.txt?number=3535 One of the interesting findings of that workshop was that one of the significant barriers to the use of SNMP as a configuration or control protocol is that it uses a binary encoding, which means that SNMP-specific client software (an SNMP browser or manager) is needed to interact with the device via SNMP. This prevents SNMP access using text processing tools or via human interaction. I would not like to see the industry create the same problem with an RFID control protocol. If there is real evidence that canonical XML would require too much code size on the reader and/or would result in an unacceptable level of protocol overhead, perhaps we could consider a protocol-specific text-based encoding (similar to FTP, SMTP and HTTP)? I don't believe that parsing a well-defined text-based encoding would require much more code than processing a binary encoding. And, in some cases a text based encoding would actually result in less data on the wire -- for instance a 32 bit integer with the value of 3 would be encoded in one byte of text ("3"), while it would require 4 bytes in binary encoding ("0x00000003'). Personally I like canonical XML, because I think it strikes a good balance between being human readable and machine-parsable. I also like the fact that the syntax is already well-defined. However, I think that well-defined, protocol-specific textual encodings could also achieve that balance, perhaps with less impact in the areas of concern (code size and protocol overhead). What do others think? Should we at least consider a text-based encoding? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 00:02:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSGT-0003SQ-Vs; Thu, 21 Jul 2005 00:02:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSGP-0003Rp-Gy for rfid@megatron.ietf.org; Thu, 21 Jul 2005 00:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04755 for ; Thu, 21 Jul 2005 00:02:21 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvSkM-0005uC-Dp for rfid@ietf.org; Thu, 21 Jul 2005 00:33:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 00:02:00 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF366@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWNkG2rVrvEuIqwSMaPjgcS/IhSOwAFgYrF From: "P. Krishna" To: "Margaret Wasserman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1664356565==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1664356565== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58DA8.F20F1CC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58DA8.F20F1CC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: rfid-bounces@lists.ietf.org on behalf of Margaret Wasserman Sent: Wed 7/20/2005 9:05 PM To: rfid@ietf.org Subject: [Rfid] SLRRP -> RRCP? Hi All, I was talking to Scott Barvick off-line, and I made a comment that is probably better shared with the list... To avoid later pain/confusion, I think it would be preferable to change the name of the SLRRP protocol to something that doesn't contain "marketing" terms like "Simple" or "Lightweight". The IESG will not generally approve documents that include those words in the title or document name, as they are seen as marketing terms, not engineering terms. I recently encountered this issue with an IPDVB WG protocol. See the comments from David Kessens at: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D11634&rfc_flag=3D0 We were forced to rename the ULE protocol in the final stages, which was a bit painful. Fortunately, we found a reasonable name that retained the commonly-used ULE acronym, or it would have been worse. Given that David is one of the area directors for this effort, I doubt that we can slip a protocol past him that claims to be both "simple" and "lightweight". In the interest of avoiding that problem if/when this group becomes a WG and wants to publish a SLRRP-inspired protocol, I'd suggest that we rename the protocol now, while it will have less impact on the effort. How about "RFID Reader Control Protocol (RRCP)"? It's not as easily pronounced, but it is more descriptive. Margaret =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Hi Margaret, Welcome back! I didn't know that one of the issues @ hand was the name = of the protocol? Thats an useful input - but dont you think the = discussion regarding renaming can wait till the group is formed? The = folks on this mailing list have been working on this protocol since = Nov'04, and this is the first time we have heard about this!=20 If the name does become a big issue, I would rather not go from one = acronym to another one, but just call it Reader Protocol - this way = there will not be any confusion. Thank you, /Krishna _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------_=_NextPart_001_01C58DA8.F20F1CC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Rfid] SLRRP -> RRCP?=0A= =0A= =0A=
=0A=
 
=0A=

=0A=
=0A= From: rfid-bounces@lists.ietf.org on = behalf of =0A= Margaret Wasserman
Sent: Wed 7/20/2005 9:05 PM
To: =0A= rfid@ietf.org
Subject: [Rfid] SLRRP -> = RRCP?

=0A=

=0A=

Hi All,

I was talking to Scott Barvick = off-line, and I =0A= made a comment that is
probably better shared with the = list...

To =0A= avoid later pain/confusion, I think it would be preferable to
change = the name =0A= of the SLRRP protocol to something that doesn't
contain "marketing" = terms =0A= like "Simple" or "Lightweight".  The IESG
will not generally = approve =0A= documents that include those words in the
title or document name, as = they are =0A= seen as marketing terms, not
engineering terms.

I recently = encountered =0A= this issue with an IPDVB WG protocol.  See the
comments from = David =0A= Kessens at:

https://datatracker.ietf.org/publi= c/pidtracker.cgi?command=3Dview_id&dTag=3D11634&rfc_flag=3D0<= BR>
We =0A= were forced to rename the ULE protocol in the final stages, which
was = a bit =0A= painful.  Fortunately, we found a reasonable name that
retained = the =0A= commonly-used ULE acronym, or it would have been worse.

Given = that David =0A= is one of the area directors for this effort, I
doubt that we can = slip a =0A= protocol past him that claims to be both
"simple" and =0A= "lightweight".

In the interest of avoiding that problem if/when = this =0A= group becomes a
WG and wants to publish a SLRRP-inspired protocol, = I'd =0A= suggest that
we rename the protocol now, while it will have less = impact on =0A= the
effort.

How about "RFID Reader Control Protocol = (RRCP)"?  =0A= It's not as easily
pronounced, but it is more = descriptive.

Margaret
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=0A=

Hi Margaret,

=0A=

Welcome back! I didn't know that one of the issues @ = hand was =0A= the name of the protocol? Thats an useful input - but dont you =0A= think the discussion regarding renaming can wait till = the group is =0A= formed? The folks on this mailing list have been working on = this =0A= protocol since Nov'04, and this is the first time we have =0A= heard about this!

=0A=

If the name does become a big issue, I would = rather not go =0A= from one acronym to another one, but just call it Reader Protocol = - this =0A= way there will not be any confusion.

=0A=

Thank you,

=0A=

/Krishna

=0A=
=0A=








__________________________________________= _____
Rfid =0A= mailing list
Rfid@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/rfid

=0A= =0A= =0A= ------_=_NextPart_001_01C58DA8.F20F1CC2-- --===============1664356565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1664356565==-- From rfid-bounces@lists.ietf.org Thu Jul 21 00:37:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSo3-00057S-Mk; Thu, 21 Jul 2005 00:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSo1-00056P-Lq for rfid@megatron.ietf.org; Thu, 21 Jul 2005 00:37:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06611 for ; Thu, 21 Jul 2005 00:37:06 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvTHz-0007yU-Ul for rfid@ietf.org; Thu, 21 Jul 2005 01:08:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 00:32:28 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF36D@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWNkG2rVrvEuIqwSMaPjgcS/IhSOwAFgYrFAAGv67c= From: "P. Krishna" To: "P. Krishna" , "Margaret Wasserman" , X-Spam-Score: 0.5 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0236531438==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0236531438== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58DAD.D2C326FA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58DAD.D2C326FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > If the name does become a big issue, I would rather not go from one = acronym to another one, but just call it Reader Protocol > - this way = there will not be any confusion. =20 Hi Margaret,=20 a faux pas in my previous email: I wanted to suggest "Reader Control Protocol" - keeping it simple and = removing the confusion of 2Rs in your RRCP proposal. =20 Regards, /Krishna =20 ------_=_NextPart_001_01C58DAD.D2C326FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= [Rfid] SLRRP -> RRCP?=0A= =0A= =0A=
> If the name = does become a =0A= big issue, I would rather not go from one acronym to another one, = but just =0A= call it Reader Protocol > - this way there will not be any =0A= confusion.
=0A=
=0A=
=0A=
=0A=
 
=0A=
Hi Margaret, =
=0A=
a faux pas in my = previous =0A= email:
=0A=
I wanted to = suggest "Reader =0A= Control Protocol" - keeping it simple and removing the confusion of 2Rs = in your =0A= RRCP proposal.
=0A=
 
=0A=
Regards,
=0A=
/Krishna
=0A=
 
=0A= =0A= =0A= ------_=_NextPart_001_01C58DAD.D2C326FA-- --===============0236531438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0236531438==-- From rfid-bounces@lists.ietf.org Thu Jul 21 07:39:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZOn-0005b2-Il; Thu, 21 Jul 2005 07:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZOl-0005Zd-GW for rfid@megatron.ietf.org; Thu, 21 Jul 2005 07:39:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21530 for ; Thu, 21 Jul 2005 07:39:30 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvZsl-0000yq-FT for rfid@ietf.org; Thu, 21 Jul 2005 08:10:33 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 446695; Thu, 21 Jul 2005 07:33:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0E03681B885F3B4296B999E34435A16EBFF36D@ms08.mse3.exchange.ms> References: <0E03681B885F3B4296B999E34435A16EBFF36D@ms08.mse3.exchange.ms> Date: Thu, 21 Jul 2005 07:39:21 -0400 To: "P. Krishna" , From: Margaret Wasserman Subject: RE: [Rfid] SLRRP -> RRCP? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi Krishna, I'm glad you wrote this second note, because I was quite surprised that you thought calling this protocol the "Reader Protocol" would be _less_ confusing. :-) Within EPC Global, it might make sense to simply call something the "Reader Protocol", as EPC Global does, because their work is entirely scoped to RFID. Within the IETF, though, I think some indication of the fact that this is a control protocol for _RFID_ readers (as opposed to barcode readers, RSS readers, etc.) is needed. Margaret At 12:32 AM -0400 7/21/05, P. Krishna wrote: > If the name does become a big issue, I would rather not go from one >acronym to another one, but just call it Reader Protocol > - this >way there will not be any confusion. Hi Margaret, a faux pas in my previous email: I wanted to suggest "Reader Control Protocol" - keeping it simple and removing the confusion of 2Rs in your RRCP proposal. Regards, /Krishna _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 08:01:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvZjk-0006Qk-Ty; Thu, 21 Jul 2005 08:01:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTle-0003dN-BZ for rfid@megatron.ietf.org; Thu, 21 Jul 2005 01:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09862 for ; Thu, 21 Jul 2005 01:38:45 -0400 (EDT) Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvUFb-00034h-VT for rfid@ietf.org; Thu, 21 Jul 2005 02:09:45 -0400 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id j6L5a2MF004075; Wed, 20 Jul 2005 22:36:03 -0700 In-Reply-To: <0E03681B885F3B4296B999E34435A16EBFF366@ms08.mse3.exchange.ms> References: <0E03681B885F3B4296B999E34435A16EBFF366@ms08.mse3.exchange.ms> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74CD3527-9564-4B06-9192-4B3A81DA3FD2@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 11:08:17 +0530 To: "P. Krishna" X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 21 Jul 2005 08:01:11 -0400 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org > Welcome back! I didn't know that one of the issues @ hand was the > name of the protocol? Thats an useful input - but dont you think > the discussion regarding renaming can wait till the group is > formed? The folks on this mailing list have been working on this > protocol since Nov'04, and this is the first time we have heard > about this! > > i think margaret raises a valid point, or more accurately two points: first, is that it's likely that the name will get changed; and, second, that it's probably better to change it earlier tather than later. i think it's reasonable to start worrying about this now... ideally, i'd like to see a new name in the charter when it's approved! /mtr _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 08:29:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaB3-0002Oi-5o; Thu, 21 Jul 2005 08:29:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaB1-0002M4-CH for rfid@megatron.ietf.org; Thu, 21 Jul 2005 08:29:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25512 for ; Thu, 21 Jul 2005 08:29:22 -0400 (EDT) Received: from caluxsmtp2.allstream.com ([209.82.17.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvaf2-0004FM-EY for rfid@ietf.org; Thu, 21 Jul 2005 09:00:26 -0400 Received: from calvs002.att-intra.com (calvs002 [10.1.1.46]) by caluxsmtp2.allstream.com (Postfix) with SMTP id 99583A32C8 for ; Thu, 21 Jul 2005 06:29:04 -0600 (MDT) Received: From torex006.att-intra.com ([10.18.6.173]) by calvs002.att-intra.com (WebShield SMTP v4.5 MR2); id 1121948884567; Thu, 21 Jul 2005 06:28:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Jul 2005 08:28:04 -0400 Message-ID: Thread-Topic: SLRRP and SNMP Thread-Index: AcWNkG2rVrvEuIqwSMaPjgcS/IhSOwAFgYrFAAGv67cAEIxJQA== From: "Frederico, Gustavo" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Subject: [Rfid] SLRRP and SNMP X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0755427884==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0755427884== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58DEF.A56688A6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58DEF.A56688A6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream ------_=_NextPart_001_01C58DEF.A56688A6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [Rfid] SLRRP -> RRCP?

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

------_=_NextPart_001_01C58DEF.A56688A6-- --===============0755427884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0755427884==-- From rfid-bounces@lists.ietf.org Thu Jul 21 08:55:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaaR-0002wX-RY; Thu, 21 Jul 2005 08:55:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvaaQ-0002wK-TV for rfid@megatron.ietf.org; Thu, 21 Jul 2005 08:55:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26833 for ; Thu, 21 Jul 2005 08:55:37 -0400 (EDT) Received: from caluxsmtp2.allstream.com ([209.82.17.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvb4R-0005kb-Qe for rfid@ietf.org; Thu, 21 Jul 2005 09:26:41 -0400 Received: from calvs002.att-intra.com (calvs002 [10.1.1.46]) by caluxsmtp2.allstream.com (Postfix) with SMTP id 8D6EBA3257 for ; Thu, 21 Jul 2005 06:55:27 -0600 (MDT) Received: From torex006.att-intra.com ([10.18.6.173]) by calvs002.att-intra.com (WebShield SMTP v4.5 MR2); id 1121950521334; Thu, 21 Jul 2005 06:55:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Thu, 21 Jul 2005 08:55:25 -0400 Message-ID: Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWNmsImysFM/F8sTzm60PozG2YbcQAVZhkw From: "Frederico, Gustavo" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org XML is already the de facto standard for interaction between disparate systems. That is clear to people that work in software and systems integration. Perhaps it's not so obvious to folks that work mostly with hardware. I would be concerned to used a protocol that is not XML-based and defines software interface. The size of XML does not have to be so much of a concern. It will probably be x % of what it would be if it were not XML-based anyway. The human-readability of XML is not a problem either, with a plethora of XML tools that facilitate editing and generation. There are lots of packages for parsing in Java, Perl and .NET compact framework. There's NanoXML, for instance, a light-weight Java xml parser that requires 6K. There is work on W3C on a binary representation of XML ( http://www.w3.org/XML/Binary/ ), but it doesn't seem to be finalized, and maybe it isn't necessary in this case either. XML brings many benefits that are well-documented. What the group may also consider is the use of RDF or OWL-Lite, for strong semantics and scalability, that I think would fit configuration management very well. Regards, Gustavo Frederico Allstream -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Margaret Wasserman Sent: Wednesday, July 20, 2005 10:19 PM To: rfid@ietf.org Subject: [Rfid] XML vs. Text vs. Binary We've had some discussion on this list about XML encoding vs. binary=20 encoding... I'm not sure that we are in agreement on all of the related points,=20 but the concerns with XML seem to be code size on the reader and=20 protocol overhead on the wire. These concerns can be minimized by=20 the use of a restricted XML subset, such as canonical XML (see RFC=20 3076). However, there still seem to be some concerns along those=20 lines. The only advantages that I remember being discussed for a binary=20 encoding were the complement to the concerns with XML: smaller code=20 size on the reader and less protocol overhead. I think, though, that our discussions have missed a major benefit of=20 any text-based encoding (whether a protocol-specific text encoding or=20 canonical XML): the ability to access the device using text=20 processing tools (such as Perl scripts) and/or for a human to=20 interact with the device directly. In 2002, the IAB held a Network Management workshop that is=20 documented in RFC 3535. I would suggest that folks on this list read=20 this report which can be found at: http://www.ietf.org/rfc/rfc3535.txt?number=3D3535 One of the interesting findings of that workshop was that one of the=20 significant barriers to the use of SNMP as a configuration or control=20 protocol is that it uses a binary encoding, which means that=20 SNMP-specific client software (an SNMP browser or manager) is needed=20 to interact with the device via SNMP. This prevents SNMP access=20 using text processing tools or via human interaction. I would not like to see the industry create the same problem with an=20 RFID control protocol. If there is real evidence that canonical XML would require too much=20 code size on the reader and/or would result in an unacceptable level=20 of protocol overhead, perhaps we could consider a protocol-specific=20 text-based encoding (similar to FTP, SMTP and HTTP)? I don't believe=20 that parsing a well-defined text-based encoding would require much=20 more code than processing a binary encoding. And, in some cases a=20 text based encoding would actually result in less data on the wire --=20 for instance a 32 bit integer with the value of 3 would be encoded in=20 one byte of text ("3"), while it would require 4 bytes in binary=20 encoding ("0x00000003'). Personally I like canonical XML, because I think it strikes a good=20 balance between being human readable and machine-parsable. I also=20 like the fact that the syntax is already well-defined. However, I=20 think that well-defined, protocol-specific textual encodings could=20 also achieve that balance, perhaps with less impact in the areas of=20 concern (code size and protocol overhead). What do others think? Should we at least consider a text-based encoding? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 09:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb57-0000GG-5D; Thu, 21 Jul 2005 09:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb56-0000FV-Bj for rfid@megatron.ietf.org; Thu, 21 Jul 2005 09:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29143 for ; Thu, 21 Jul 2005 09:27:18 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvbZ7-0007jK-GO for rfid@ietf.org; Thu, 21 Jul 2005 09:58:23 -0400 Received: from ([10.100.101.63]) by relay1.manh.com with ESMTP id 4029082.14711287; Thu, 21 Jul 2005 09:26:12 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 09:26:12 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 09:26:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 09:26:11 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBC8@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP and SNMP Thread-Index: AcWNkG2rVrvEuIqwSMaPjgcS/IhSOwAFgYrFAAGv67cAEIxJQAAB/PaA From: "Howard Kapustein" To: "Frederico, Gustavo" , X-OriginalArrivalTime: 21 Jul 2005 13:26:12.0103 (UTC) FILETIME=[C32F6970:01C58DF7] X-Spam-Score: 0.2 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0875009607==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0875009607== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58DF7.C3054856" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58DF7.C3054856 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One delta: =20 SNMP =3D management SLRRP =3D operations =20 SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 SLRRP targets questions like "how do I know what tags are passing by a reader" SNMP targets questions like "how do I know the reader is working" =20 Things like Tivoli/OpenView/... care about the latter. Things like warehouse management systems care about the former. =20 - Howard =20 ________________________________ From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 8:28 AM To: rfid@ietf.org Subject: [Rfid] SLRRP and SNMP =20 =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream ------_=_NextPart_001_01C58DF7.C3054856 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Rfid] SLRRP -> RRCP?

One = delta:

 

SNMP =3D = management

SLRRP =3D = operations

 

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

SLRRP targets questions like = “how do I know what tags are passing by a = reader”

SNMP targets questions like = “how do I know the reader is working”

 

Things like Tivoli/OpenView/… = care about the latter.

Things like warehouse management = systems care about the former.

 

      =       - Howard

 

From: = rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo
Sent: Thursday, July 21, = 2005 8:28 AM
To: rfid@ietf.org
Subject: [Rfid] SLRRP and = SNMP

 

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

------_=_NextPart_001_01C58DF7.C3054856-- --===============0875009607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0875009607==-- From rfid-bounces@lists.ietf.org Thu Jul 21 12:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdkY-0002dr-Jk; Thu, 21 Jul 2005 12:18:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdkW-0002bk-22 for rfid@megatron.ietf.org; Thu, 21 Jul 2005 12:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13877 for ; Thu, 21 Jul 2005 12:18:13 -0400 (EDT) Received: from petasus.ch.intel.com ([143.182.124.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DveEZ-0002LO-86 for rfid@ietf.org; Thu, 21 Jul 2005 12:49:20 -0400 Received: from azsmsxvs041.ch.intel.com (azsmsxvs041.ch.intel.com [143.182.252.55]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.10/d: small-solo.mc,v 1.2 2004/09/17 18:05:04 root Exp $) with SMTP id j6LGFFIZ021127; Thu, 21 Jul 2005 16:15:17 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs041.ch.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005072109173814784 ; Thu, 21 Jul 2005 09:17:38 -0700 Received: from azsmsx404.amr.corp.intel.com ([10.2.161.27]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 09:17:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 09:17:37 -0700 Message-ID: Thread-Topic: [Rfid] SLRRP and SNMP Thread-Index: AcWOD7W90smDh92hTTSJCqbS2uILHw== From: "Mountain, Highland M" To: "Howard Kapustein" , "Frederico, Gustavo" , X-OriginalArrivalTime: 21 Jul 2005 16:17:38.0908 (UTC) FILETIME=[B69949C0:01C58E0F] X-Spam-Score: 0.2 (/) X-Scan-Signature: b94423d57458a72e07b422b40e685d94 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0158186359==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0158186359== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E0F.B643873D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E0F.B643873D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howard wrote>SNMP targets questions like "how do I know the reader is working" =20 But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? Is there not potential for some overlap here? =20 Howard wrote> SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 One can look at other device classes and see device operations outside of network operations captured by standard MIBs. Take the printer mib for example. =20 =20 Thoughts? =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 6:26 AM To: Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 One delta: =20 SNMP =3D management SLRRP =3D operations =20 SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 SLRRP targets questions like "how do I know what tags are passing by a reader" SNMP targets questions like "how do I know the reader is working" =20 Things like Tivoli/OpenView/... care about the latter. Things like warehouse management systems care about the former. =20 - Howard =20 ________________________________ From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 8:28 AM To: rfid@ietf.org Subject: [Rfid] SLRRP and SNMP =20 =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream ------_=_NextPart_001_01C58E0F.B643873D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Rfid] SLRRP -> RRCP?

Howard wrote>SNMP targets = questions like “how do I know the reader is = working”

 

But if the tags are not passing = through the reader, then the reader is not working ~ SNMP issue with an RFID = twist?  Is there not potential for some overlap here?

 

Howard = wrote>

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

One can look at other device = classes and see device operations outside of network operations captured by standard = MIBs.  Take the printer mib for example. 

 

Thoughts?

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 6:26 AM
To: Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

One = delta:

 

SNMP =3D = management

SLRRP =3D = operations

 

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

SLRRP targets questions like = “how do I know what tags are passing by a = reader”

SNMP targets questions like = “how do I know the reader is working”

 

Things like Tivoli/OpenView/… = care about the latter.

Things like warehouse management = systems care about the former.

 

      =       - Howard

 

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] = On Behalf Of Frederico, = Gustavo
Sent: Thursday, July 21, = 2005 8:28 AM
To: rfid@ietf.org
Subject: [Rfid] SLRRP and = SNMP

 

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

------_=_NextPart_001_01C58E0F.B643873D-- --===============0158186359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0158186359==-- From rfid-bounces@lists.ietf.org Thu Jul 21 12:31:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdxY-00016X-Oy; Thu, 21 Jul 2005 12:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvdxW-00016S-VV for rfid@megatron.ietf.org; Thu, 21 Jul 2005 12:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15046 for ; Thu, 21 Jul 2005 12:31:40 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DveRa-0003D8-FC for rfid@ietf.org; Thu, 21 Jul 2005 13:02:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 12:31:17 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E01234A6D@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWN7B+24TvIUCRYRXqaeqO+7qw+MwAG3uXQ From: "David Husak" To: "Marshall Rose" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org For the record, the protocol was Simple, the reader was Lightweight:)=20 If we've run afoul of current naming practice, I'm all for changing the name now. We've already built some name equity for SLRRP (I will admit that's entirely due to the provocative pronunciation), but if change is inevitable, the sooner, the better. I'm fine with RCP or RRCP... I'd also put R2CP, or even just R2C, in the mix. It can have the double meaning of R-squared-C =3D RRC for RFID = Reader Control, as well as "Reader-to-Controller". The trailing 'P' has always struck me as sort-of redundant or implied, since you'll typically hear people say things like "... the XXXXP protocol." Any other candidates out there? Dave ------------------------ David J. Husak Reva Systems Corporation dhusak@revasystems.com=20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Marshall Rose > Sent: Thursday, July 21, 2005 1:38 AM > To: P. Krishna > Cc: rfid@ietf.org > Subject: Re: [Rfid] SLRRP -> RRCP? >=20 > i think margaret raises a valid point, or more accurately two points: > first, is that it's likely that the name will get changed; and, > second, that it's probably better to change it earlier tather than > later. >=20 > i think it's reasonable to start worrying about this now... ideally, > i'd like to see a new name in the charter when it's approved! >=20 > /mtr >=20 >=20 >=20 >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 12:41:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dve7J-0006HA-2I; Thu, 21 Jul 2005 12:41:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dve7H-0006Fp-93 for rfid@megatron.ietf.org; Thu, 21 Jul 2005 12:41:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16775 for ; Thu, 21 Jul 2005 12:41:44 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvebK-00045R-TZ for rfid@ietf.org; Thu, 21 Jul 2005 13:12:51 -0400 Received: from ([10.100.101.63]) by relay1.manh.com with ESMTP id 4029082.14730169; Thu, 21 Jul 2005 12:40:35 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 12:40:35 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 12:40:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 12:40:34 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBD7@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP and SNMP Thread-Index: AcWOD7W90smDh92hTTSJCqbS2uILHwAAMCSA From: "Howard Kapustein" To: "Mountain, Highland M" , "Frederico, Gustavo" , X-OriginalArrivalTime: 21 Jul 2005 16:40:34.0757 (UTC) FILETIME=[EAAB2F50:01C58E12] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7418200ea0c73569681eb45a76a492d4 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999516718==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1999516718== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E12.EA833695" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E12.EA833695 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? If the reader reports no tags, is that because the reader's broken, the tags are broken, or there really are no tags to read? =20 I'd expect 0 tag reads for a reader monitoring a dock door if nothing goes thru the dock door. =20 =20 >Is there not potential for some overlap here? No. Take a reader with a wire to the antenna and fry the antenna, where the reader will power up but the antenna won't work. Some readers have no built-in diagnostics and will blithely run, never reading anything from that antenna. =20 Or even better, bake in diagnostics but now have a *partially* working antenna, only working at, say, half the expected range/power/whatever. =20 SNMP is designed for such use cases. =20 The *consumers* of the data is very different. Management vs. Operation data. Management vs. Operation systems. =20 Tivoli cares about very different events and information than Warehouse Management systems. =20 =20 There's some overlap between "management" and "configuration" (where the latter can be viewed as a subset of the former), but pragmatically you can't divorce "configuration" from the operations side of the system. [Well, you can, but it creates other headaches.] =20 The use cases and issues surrounding "management" and "operations" are different, hence the reason SNMP may be a strong candidate for the former (well, the SNMP protocol plus some MIBs), but a poor option for the latter. =20 =20 FYI there's enough of a delta here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; RP 1.0's goal was "Reading, Writing and Killing tags, and operations needed to support that" vs. RM 1.0's goal was (loosely stated) "managing readers". =20 That said, the RP+RM workgroups had a lot of overlap, and frequently collaborated to varying degrees to jointly design solutions. =20 =20 >One can look at other device classes and see device operations outside of network operations captured by standard MIBs. >Take the printer mib for example. =20 Yes, very true. But SNMP doesn't fit very well for operational behaviors (reading/writing/killing), for a variety of reasons. Certainly you -could- use SNMP to read tag info from a reader, but it's not a good option. Do *you* know of any application that uses SNMP to print a document on a printer, instead of a "print" api/protocol?=20 =20 =20 =20 Here's a simpler way to think of your original question: Change "RFID reader" + "SLRRP" to "web server" + "HTTP". =20 Can you please compare HTTP and SNMP in their intentions? =20 - Howard =20 =20 ________________________________ From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]=20 Sent: Thursday, July 21, 2005 12:18 PM To: Howard Kapustein; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 Howard wrote>SNMP targets questions like "how do I know the reader is working" =20 But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? Is there not potential for some overlap here? =20 Howard wrote> SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 One can look at other device classes and see device operations outside of network operations captured by standard MIBs. Take the printer mib for example. =20 =20 Thoughts? =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 6:26 AM To: Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 One delta: =20 SNMP =3D management SLRRP =3D operations =20 SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 SLRRP targets questions like "how do I know what tags are passing by a reader" SNMP targets questions like "how do I know the reader is working" =20 Things like Tivoli/OpenView/... care about the latter. Things like warehouse management systems care about the former. =20 - Howard =20 ________________________________ From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 8:28 AM To: rfid@ietf.org Subject: [Rfid] SLRRP and SNMP =20 =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream ------_=_NextPart_001_01C58E12.EA833695 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Rfid] SLRRP -> RRCP?

>But if the tags are not passing through the reader, then the reader is not = working ~ SNMP issue with an RFID twist?

If the reader reports no tags, is = that because the reader’s broken, the tags are broken, or there really = are no tags to read?

 

I’d expect 0 tag reads for a = reader monitoring a dock door if nothing goes thru the dock = door.

 

 

>Is there not potential for some overlap = here?

No.

Take a reader with a wire to the = antenna and fry the antenna, where the reader will power up but the antenna = won’t work. Some readers have no built-in diagnostics and will blithely run, = never reading anything from that antenna.

 

Or even better, bake in diagnostics = but now have a *partially* = working antenna, only working at, say, half the expected = range/power/whatever.

 

SNMP is designed for such use = cases.

 

The *consumers* of the data is very different.

Management vs. Operation = data.

Management vs. Operation = systems.

 

Tivoli cares about very different events and information than = Warehouse Management systems.

 

 

There’s some overlap between = “management” and “configuration” (where the latter can be viewed as a = subset of the former), but pragmatically you can’t divorce = “configuration” from the operations side of the system. [Well, you can, but it creates = other headaches.]

 

The use cases and issues = surrounding “management” and “operations” are different, hence the reason SNMP may be = a strong candidate for the former (well, the SNMP protocol plus some = MIBs), but a poor option for the latter.

 

 

FYI there’s enough of a delta = here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; = RP 1.0’s goal was “Reading, Writing and Killing tags, and operations needed = to support that” vs. RM 1.0’s goal was (loosely stated) = “managing readers”.

 

That said, the RP+RM workgroups had = a lot of overlap, and frequently collaborated to varying degrees to jointly = design solutions.

 

 

>One can look at other device classes and see device operations outside of = network operations captured by standard MIBs.

>Take the printer mib for example. 

Yes, very = true.

But SNMP doesn’t fit very = well for operational behaviors (reading/writing/killing), for a variety of = reasons.

Certainly you -could- use SNMP to = read tag info from a reader, but it’s not a good = option.

Do *you* know of any application that uses SNMP to print a document on a printer, instead of a “print” api/protocol? =

 

 

 

Here’s a simpler way to think = of your original question:

Change “RFID reader” + = “SLRRP” to “web server” + = “HTTP”.

 

Can you please compare HTTP and = SNMP in their intentions?

 

      =       - Howard

 

 

From: = Mountain, Highland M [mailto:highland.m.mountain@intel.com]
Sent: Thursday, July 21, = 2005 12:18 PM
To: Howard Kapustein; = Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

Howard wrote>SNMP targets = questions like “how do I know the reader is = working”

 

But if the tags are not passing = through the reader, then the reader is not working ~ SNMP issue with an RFID = twist?  Is there not potential for some overlap = here?

 

Howard = wrote>

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

One can look at other device = classes and see device operations outside of network operations captured by standard MIBs.  Take the printer mib for example.  =

 

Thoughts?

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 6:26 AM
To: Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

One = delta:

 

SNMP =3D = management

SLRRP =3D = operations

 

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

SLRRP targets questions like = “how do I know what tags are passing by a = reader”

SNMP targets questions like = “how do I know the reader is working”

 

Things like Tivoli/OpenView/… = care about the latter.

Things like warehouse management = systems care about the former.

 

      =       - Howard

 

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] = On Behalf Of Frederico, = Gustavo
Sent: Thursday, July 21, = 2005 8:28 AM
To: rfid@ietf.org
Subject: [Rfid] SLRRP and = SNMP

 

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

------_=_NextPart_001_01C58E12.EA833695-- --===============1999516718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1999516718==-- From rfid-bounces@lists.ietf.org Thu Jul 21 13:19:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvehq-0006Qp-LJ; Thu, 21 Jul 2005 13:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvehp-0006Qk-Rs for rfid@megatron.ietf.org; Thu, 21 Jul 2005 13:19:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19282 for ; Thu, 21 Jul 2005 13:19:30 -0400 (EDT) Received: from mail.intelleflex.com ([66.236.103.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvfBt-00078b-5F for rfid@ietf.org; Thu, 21 Jul 2005 13:50:38 -0400 Received: from SureshLaptopIF (SureshLaptopIF.intelleflex.com [10.1.7.166]) by mail.intelleflex.com (8.13.3/8.13.3) with ESMTP id j6LHKCx4004859 for ; Thu, 21 Jul 2005 10:20:12 -0700 Message-Id: <200507211720.j6LHKCx4004859@mail.intelleflex.com> From: "Suresh Bhaskaran" To: Subject: FW: [Rfid] SLRRP Vendor Extensions Date: Thu, 21 Jul 2005 10:19:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWNfLHlhtQuY6LsRO6C2fdoyUyQAQAB1vEwACT7dUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Scanned-By: MIMEDefang 2.49 on 10.1.7.25 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org -----Original Message----- Oops. Thanks for he reminder, Peter. I had meant to send this to the entire list. Suresh ------------------------ From: Suresh Bhaskaran [mailto:sbhaskaran@intelleflex.com] Sent: Wednesday, July 20, 2005 4:42 PM To: 'Peter Spreadborough' Subject: RE: [Rfid] SLRRP Vendor Extensions The way this is defined, the vendor ID is a required field for *all* message headers now? Is this the intention? Might there be a way to leave the messages the same, and only include the vendor ID in the message header if it is a vendor extension? The V-bit as stated, is only for the parameter. If we had the equivalent of a V-bit for the message, then we don't have to include the Vendor ID in all message headers? Suresh -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Peter Spreadborough Sent: Wednesday, July 20, 2005 3:44 PM To: rfid@ietf.org Subject: [Rfid] SLRRP Vendor Extensions To facilitate the support of vendor specific extensions, prior to formal inclusion into the protocol, the following solution is proposed: 1. The SLRRP message header will be extended to include a thirty two bit vendor ID field: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|x| Ver | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |x x x x x x x x x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Message Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. For SLRRP parameters a bit from the "user" bits will be assigned as the Vendor or V bit. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |V|User | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Parameter Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. A block of unused message types will be reserved for vendor extensions. 4. A block of parameter types will be reserved for vendor extensions. SLRRP implementations may choose to ignore: - Any message types that fall in to the vendor extension range. - Any parameter types that fall into the vendor extension range. - Any parameters that have the V bit set. If the V bit is set in a parameter header then the vendor ID used in the encapsulating message will apply. The parameter may then be accepted or ignored based on the vendor ID. This applies to both defined message types and extended message types. _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 14:05:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfQB-0003my-OY; Thu, 21 Jul 2005 14:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfQ9-0003iR-8u for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:05:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22348 for ; Thu, 21 Jul 2005 14:05:20 -0400 (EDT) Received: from petasus.ch.intel.com ([143.182.124.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvfuD-0001cD-8g for rfid@ietf.org; Thu, 21 Jul 2005 14:36:26 -0400 Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [143.182.252.54]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.10/d: small-solo.mc,v 1.2 2004/09/17 18:05:04 root Exp $) with SMTP id j6LI2bIf013625; Thu, 21 Jul 2005 18:02:41 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs040.ch.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005072111050227579 ; Thu, 21 Jul 2005 11:05:02 -0700 Received: from azsmsx404.amr.corp.intel.com ([10.2.161.27]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 11:05:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 11:05:01 -0700 Message-ID: Thread-Topic: RE: [Rfid] SLRRP and SNMP Thread-Index: AcWOHra5UQc4POUGQJmJNtJuCTJxIw== From: "Mountain, Highland M" To: "Howard Kapustein" X-OriginalArrivalTime: 21 Jul 2005 18:05:02.0766 (UTC) FILETIME=[B76FFCE0:01C58E1E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6b835336d254034fcc92a13cb7bf8f2d Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810720224==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1810720224== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E1E.B6FD2982" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E1E.B6FD2982 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >>One can look at other device classes and see device operations outside of network operations captured by standard MIBs. >>Take the printer mib for example. =20 >Yes, very true. >>Good, at least we agree on something. >But SNMP doesn't fit very well for operational behaviors (reading/writing/killing), for a variety of reasons. =20 Right, I never proposed SNMP should be used for such operational behaviors, nor did I say the Printer MIB promotes printing docs through SNMP. What I see is the usefulness of the data being discussed in SLRRP within SNMP. =20 Are you promoting SNMP=3D *management* using only those well known mibs which have gone before (MIB-2, HOST-RESOURCES) without the potential of new MIBs in the RFID reader space? =20 =20 Let me rephrase one of my original statements: =20 But if the tags are not passing through the reader, because there is a problem with the Reader, then the reader is not working and someone should be notified to fix it ~ SNMP issue with an RFID twist? =20 =20 Once an SNMP manager receives a trap relating to the above, would it not be useful to at least *view* relevant RFID related operational/configuration info through an RFID reader MIB to aid in diagnosing the problem. Data like Antenna Configuration, Reader Capabilities, and General tag read statistics could be useful in some cases. =20 =20 How do Warehouse Management systems handle device faults and troubleshooting? Is their a notion of traps/alerts in these systems? =20 =20 =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 9:41 AM To: Mountain, Highland M; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 >But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? If the reader reports no tags, is that because the reader's broken, the tags are broken, or there really are no tags to read? =20 I'd expect 0 tag reads for a reader monitoring a dock door if nothing goes thru the dock door. =20 =20 >Is there not potential for some overlap here? No. Take a reader with a wire to the antenna and fry the antenna, where the reader will power up but the antenna won't work. Some readers have no built-in diagnostics and will blithely run, never reading anything from that antenna. =20 Or even better, bake in diagnostics but now have a *partially* working antenna, only working at, say, half the expected range/power/whatever. =20 SNMP is designed for such use cases. =20 The *consumers* of the data is very different. Management vs. Operation data. Management vs. Operation systems. =20 Tivoli cares about very different events and information than Warehouse Management systems. =20 =20 There's some overlap between "management" and "configuration" (where the latter can be viewed as a subset of the former), but pragmatically you can't divorce "configuration" from the operations side of the system. [Well, you can, but it creates other headaches.] =20 The use cases and issues surrounding "management" and "operations" are different, hence the reason SNMP may be a strong candidate for the former (well, the SNMP protocol plus some MIBs), but a poor option for the latter. =20 =20 FYI there's enough of a delta here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; RP 1.0's goal was "Reading, Writing and Killing tags, and operations needed to support that" vs. RM 1.0's goal was (loosely stated) "managing readers". =20 That said, the RP+RM workgroups had a lot of overlap, and frequently collaborated to varying degrees to jointly design solutions. =20 =20 >One can look at other device classes and see device operations outside of network operations captured by standard MIBs. >Take the printer mib for example. =20 Yes, very true. But SNMP doesn't fit very well for operational behaviors (reading/writing/killing), for a variety of reasons. Certainly you -could- use SNMP to read tag info from a reader, but it's not a good option. Do *you* know of any application that uses SNMP to print a document on a printer, instead of a "print" api/protocol?=20 =20 =20 =20 Here's a simpler way to think of your original question: Change "RFID reader" + "SLRRP" to "web server" + "HTTP". =20 Can you please compare HTTP and SNMP in their intentions? =20 - Howard =20 =20 ________________________________ From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]=20 Sent: Thursday, July 21, 2005 12:18 PM To: Howard Kapustein; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 Howard wrote>SNMP targets questions like "how do I know the reader is working" =20 But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? Is there not potential for some overlap here? =20 Howard wrote> SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 One can look at other device classes and see device operations outside of network operations captured by standard MIBs. Take the printer mib for example. =20 =20 Thoughts? =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 6:26 AM To: Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 One delta: =20 SNMP =3D management SLRRP =3D operations =20 SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 SLRRP targets questions like "how do I know what tags are passing by a reader" SNMP targets questions like "how do I know the reader is working" =20 Things like Tivoli/OpenView/... care about the latter. Things like warehouse management systems care about the former. =20 - Howard =20 ________________________________ From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 8:28 AM To: rfid@ietf.org Subject: [Rfid] SLRRP and SNMP =20 =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream =20 =20 ------_=_NextPart_001_01C58E1E.B6FD2982 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

>>One can look at other device classes and see device operations outside of = network operations captured by standard MIBs.

>>Take the printer mib for example. 

>Yes, very true.  = >>Good, at least we agree on something.

>But SNMP doesn’t fit very = well for operational behaviors (reading/writing/killing), for a variety of = reasons.

 

Right, I never proposed SNMP should = be used for such operational behaviors, nor did I say the Printer MIB = promotes printing docs through SNMP.  What I see is the usefulness of the = data being discussed in SLRRP within SNMP.

 

Are you promoting SNMP=3D *management* using only those well = known mibs which have gone before (MIB-2, HOST-RESOURCES) without the = potential of new MIBs in the RFID reader space?

 

 

Let me rephrase one of my original statements:

 

But if the tags are not passing = through the reader, because there is a = problem with the Reader, then the reader is not working and someone should = be notified to fix it ~ SNMP issue with an RFID twist?  =

 

Once an SNMP manager receives a = trap relating to the above, would it not be useful to at least *view* relevant RFID related = operational/configuration info through an RFID reader MIB to aid in diagnosing the problem.  = Data like Antenna Configuration, Reader Capabilities, and General tag read statistics could be useful in some cases.  =

 

How do Warehouse Management systems = handle device faults and troubleshooting?  Is their a notion of = traps/alerts in these systems?

 

 

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 9:41 AM
To: Mountain, Highland M; = Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

>But if the tags are not passing through the reader, then the reader is not = working ~ SNMP issue with an RFID twist?

If the reader reports no tags, is = that because the reader’s broken, the tags are broken, or there really = are no tags to read?

 

I’d expect 0 tag reads for a = reader monitoring a dock door if nothing goes thru the dock = door.

 

 

>Is there not potential for some overlap = here?

No.

Take a reader with a wire to the = antenna and fry the antenna, where the reader will power up but the antenna = won’t work. Some readers have no built-in diagnostics and will blithely run, = never reading anything from that antenna.

 

Or even better, bake in diagnostics = but now have a *partially* = working antenna, only working at, say, half the expected = range/power/whatever.

 

SNMP is designed for such use = cases.

 

The *consumers* of the data is very different.

Management vs. Operation = data.

Management vs. Operation = systems.

 

Tivoli cares about very different events and information than = Warehouse Management systems.

 

 

There’s some overlap between “management” and “configuration” (where the = latter can be viewed as a subset of the former), but pragmatically you can’t = divorce “configuration” from the operations side of the system. = [Well, you can, but it creates other headaches.]

 

The use cases and issues = surrounding “management” and “operations” are different, = hence the reason SNMP may be a strong candidate for the former (well, the SNMP = protocol plus some MIBs), but a poor option for the = latter.

 

 

FYI there’s enough of a delta = here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; = RP 1.0’s goal was “Reading, Writing and Killing tags, and = operations needed to support that” vs. RM 1.0’s goal was (loosely = stated) “managing readers”.

 

That said, the RP+RM workgroups had = a lot of overlap, and frequently collaborated to varying degrees to jointly = design solutions.

 

 

>One can look at other device classes and see device operations outside of = network operations captured by standard MIBs.

>Take the printer mib for example. 

Yes, very = true.

But SNMP doesn’t fit very = well for operational behaviors (reading/writing/killing), for a variety of = reasons.

Certainly you -could- use SNMP to = read tag info from a reader, but it’s not a good = option.

Do *you* know of any application that uses SNMP to print a document on a printer, instead of a “print” api/protocol? =

 

 

 

Here’s a simpler way to think = of your original question:

Change “RFID reader” + “SLRRP” to “web server” + = “HTTP”.

 

Can you please compare HTTP and = SNMP in their intentions?

 

      =       - Howard

 

 

From: = Mountain, Highland M [mailto:highland.m.mountain@intel.com]
Sent: Thursday, July 21, = 2005 12:18 PM
To: Howard Kapustein; = Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

Howard wrote>SNMP targets = questions like “how do I know the reader is = working”

 

But if the tags are not passing = through the reader, then the reader is not working ~ SNMP issue with an RFID twist?  Is there not potential for some overlap = here?

 

Howard = wrote>

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

One can look at other device = classes and see device operations outside of network operations captured by standard MIBs.  Take the printer mib for example.  =

 

Thoughts?

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 6:26 AM
To: Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

One = delta:

 

SNMP =3D = management

SLRRP =3D = operations

 

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

SLRRP targets questions like = “how do I know what tags are passing by a = reader”

SNMP targets questions like = “how do I know the reader is working”

 

Things like Tivoli/OpenView/… = care about the latter.

Things like warehouse management = systems care about the former.

 

      =       - Howard

 

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] = On Behalf Of Frederico, = Gustavo
Sent: Thursday, July 21, = 2005 8:28 AM
To: rfid@ietf.org
Subject: [Rfid] SLRRP and = SNMP

 

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

 

 

------_=_NextPart_001_01C58E1E.B6FD2982-- --===============1810720224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1810720224==-- From rfid-bounces@lists.ietf.org Thu Jul 21 14:15:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfXb-0007Mv-CZ; Thu, 21 Jul 2005 14:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfXZ-0007Mp-RG for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:13:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23151 for ; Thu, 21 Jul 2005 14:13:00 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvg1d-00028v-S1 for rfid@ietf.org; Thu, 21 Jul 2005 14:44:07 -0400 Received: from ([10.100.101.65]) by relay1.manh.com with ESMTP id 4029082.14739632; Thu, 21 Jul 2005 14:11:58 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 14:12:00 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 14:11:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 14:12:07 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBDE@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWN7B+24TvIUCRYRXqaeqO+7qw+MwAG3uXQAAXg2fA= From: "Howard Kapustein" To: "David Husak" , "Marshall Rose" X-OriginalArrivalTime: 21 Jul 2005 18:11:56.0544 (UTC) FILETIME=[AE118000:01C58E1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >The trailing 'P' has always >struck me as sort-of redundant or implied, since you'll typically hear >people say things like "... the XXXXP protocol." But not unprecedented. For instance, HyperText Transport Protocol has had some middling success... Not that I'm suggesting one way or the other, just that XXXXP isn't necessarily bad. - Howard P.S. Google for "rfc http hyper" and guess the 1st hit http://www.faqs.org/rfcs/rfc2324.html Another example of XXXXP Also an example that truly anyone can get anything proposed as an Internet-Draft :-> -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of David Husak Sent: Thursday, July 21, 2005 12:31 PM To: Marshall Rose Cc: rfid@ietf.org Subject: RE: [Rfid] SLRRP -> RRCP? For the record, the protocol was Simple, the reader was Lightweight:)=20 If we've run afoul of current naming practice, I'm all for changing the name now. We've already built some name equity for SLRRP (I will admit that's entirely due to the provocative pronunciation), but if change is inevitable, the sooner, the better. I'm fine with RCP or RRCP... I'd also put R2CP, or even just R2C, in the mix. It can have the double meaning of R-squared-C =3D RRC for RFID = Reader Control, as well as "Reader-to-Controller". The trailing 'P' has always struck me as sort-of redundant or implied, since you'll typically hear people say things like "... the XXXXP protocol." Any other candidates out there? Dave ------------------------ David J. Husak Reva Systems Corporation dhusak@revasystems.com=20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Marshall Rose > Sent: Thursday, July 21, 2005 1:38 AM > To: P. Krishna > Cc: rfid@ietf.org > Subject: Re: [Rfid] SLRRP -> RRCP? >=20 > i think margaret raises a valid point, or more accurately two points: > first, is that it's likely that the name will get changed; and, > second, that it's probably better to change it earlier tather than > later. >=20 > i think it's reasonable to start worrying about this now... ideally, > i'd like to see a new name in the charter when it's approved! >=20 > /mtr >=20 >=20 >=20 >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 14:34:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfsP-0000Vo-6r; Thu, 21 Jul 2005 14:34:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfsN-0000TF-8P for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25216 for ; Thu, 21 Jul 2005 14:34:29 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgMS-0003at-MB for rfid@ietf.org; Thu, 21 Jul 2005 15:05:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 14:34:19 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E01234B06@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWN7B+24TvIUCRYRXqaeqO+7qw+MwAG3uXQAAXg2fAAAM8usA== From: "David Husak" To: "Howard Kapustein" X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Howard,=20 Remember, it's important to take the date of an RFC into consideration when evaluating its merits:) Dave ------------------------ David J. Husak Reva Systems Corporation dhusak@revasystems.com > -----Original Message----- > From: Howard Kapustein [mailto:hkapustein@manh.com] > Sent: Thursday, July 21, 2005 2:12 PM > To: David Husak; Marshall Rose > Cc: rfid@ietf.org > Subject: RE: [Rfid] SLRRP -> RRCP? >=20 > >The trailing 'P' has always > >struck me as sort-of redundant or implied, since you'll typically hear > >people say things like "... the XXXXP protocol." >=20 > But not unprecedented. > For instance, HyperText Transport Protocol has had some middling > success... >=20 > Not that I'm suggesting one way or the other, just that XXXXP isn't > necessarily bad. >=20 > - Howard >=20 > P.S. Google for "rfc http hyper" and guess the 1st hit > http://www.faqs.org/rfcs/rfc2324.html > Another example of XXXXP >=20 > Also an example that truly anyone can get anything proposed as an > Internet-Draft :-> >=20 >=20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] > On Behalf Of David Husak > Sent: Thursday, July 21, 2005 12:31 PM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: RE: [Rfid] SLRRP -> RRCP? >=20 >=20 > For the record, the protocol was Simple, the reader was Lightweight:) >=20 > If we've run afoul of current naming practice, I'm all for changing the > name now. We've already built some name equity for SLRRP (I will admit > that's entirely due to the provocative pronunciation), but if change is > inevitable, the sooner, the better. >=20 > I'm fine with RCP or RRCP... I'd also put R2CP, or even just R2C, in the > mix. It can have the double meaning of R-squared-C =3D RRC for RFID Reader > Control, as well as "Reader-to-Controller". The trailing 'P' has always > struck me as sort-of redundant or implied, since you'll typically hear > people say things like "... the XXXXP protocol." >=20 > Any other candidates out there? >=20 > Dave >=20 >=20 > ------------------------ > David J. Husak > Reva Systems Corporation > dhusak@revasystems.com >=20 > > -----Original Message----- > > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] > On > > Behalf Of Marshall Rose > > Sent: Thursday, July 21, 2005 1:38 AM > > To: P. Krishna > > Cc: rfid@ietf.org > > Subject: Re: [Rfid] SLRRP -> RRCP? > > > > i think margaret raises a valid point, or more accurately two points: > > first, is that it's likely that the name will get changed; and, > > second, that it's probably better to change it earlier tather than > > later. > > > > i think it's reasonable to start worrying about this now... ideally, > > i'd like to see a new name in the charter when it's approved! > > > > /mtr > > > > > > > > > > _______________________________________________ > > Rfid mailing list > > Rfid@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/rfid >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 14:36:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfuA-0000ol-3d; Thu, 21 Jul 2005 14:36:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfu9-0000og-8E for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:36:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25361 for ; Thu, 21 Jul 2005 14:36:19 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgOD-0003kL-Cb for rfid@ietf.org; Thu, 21 Jul 2005 15:07:26 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 447243; Thu, 21 Jul 2005 14:30:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <02254DCB1D0B2340B8D1D54E770CAE76DAEBD7@ma-atl57.us.manh.com> References: <02254DCB1D0B2340B8D1D54E770CAE76DAEBD7@ma-atl57.us.manh.com> Date: Thu, 21 Jul 2005 14:32:41 -0400 To: "Howard Kapustein" , "Mountain, Highland M" , "Frederico, Gustavo" , From: Margaret Wasserman Subject: RE: [Rfid] SLRRP and SNMP Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org At 12:40 PM -0400 7/21/05, Howard Kapustein wrote: >But if the tags are not passing through the reader, then the reader >is not working ~ SNMP issue with an RFID twist? If the reader reports no tags, is that because the reader's broken, the tags are broken, or there really are no tags to read? I'd expect 0 tag reads for a reader monitoring a dock door if nothing goes thru the dock door. I actually think that there will be people who want to monitor a count of the tag reads performed by a reader, or on a particular antenna. If there is a counter available for that purpose, it can also be used for threshhold alarms -- turn the reader icon red if it hasn't read any tags in the past 10 minutes, for example. When combined with other sensors (electric eyes, sensors that detect when doors are open, motion sensors, etc.), it might also be possible to generate a more serious alarm if the reader should be reading tags, but isn't (i.e. when items are passing by and/or the door is open). I would consider all of those items to fall under management or monitoring, and I think that SNMP is a better technology for that purpose than a proprietary protocol. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 14:41:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfyr-0002gE-GP; Thu, 21 Jul 2005 14:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfyp-0002e5-Sq for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25851 for ; Thu, 21 Jul 2005 14:41:10 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgSu-00043W-Gc for rfid@ietf.org; Thu, 21 Jul 2005 15:12:17 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 447252 for rfid@ietf.org; Thu, 21 Jul 2005 14:35:04 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jul 2005 14:40:09 -0400 To: rfid@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Rfid] Supported Reader Paradigms X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Discussing the management/monitoring side of readers reminded me of another issue that I wanted to raise with this group: What paradigms should be supported for reader operations? IMO, we should think carefully about the extent to which we expect RFID readers to be controlled in a top-down fashion (receiving commands from a "controller", whether those commands are immediate or trigger-based) vs. the extent that we expect readers to be autonomous and to operate based on configured policies or rules. For example, it is quite possible to think of an RFID reader that reads pallet tags and passes them to an application, but that triggers local alarms (a flashing light, a buzzer?) if certain anomalous events occur, such as sensing a tag that is not programmed with an EPC ID or sensing a case-level or item-level tag when there is no pallet tag present in the field of view. In both of these cases, the alarm might indicate that further intervention (such as using a fall-back barcode reader) is needed. You could also picture a multi-antenna reader that report inbound items to middleware (items that are read outside the door and are later read inside the door), but that triggers an alarm if an item is moved in the opposite direction. Could SLRRP support these types of operations? If so, how? Also, there is much to be said for having readers that continue to operate when they do not have network connectivity to the controller, storing events and reporting them if/when a connection is established. Ideally, readers should be able to perform their tasks even if they are rebooted (due to a power outage, for example) and have not yet established a connection to a controller since rebooting. They should come up performing their function, and store data for later retrieval by middleware or applications. Could SLRRP support this type of autonomous operation? If so, how? _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 14:41:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfyt-0002gs-QB; Thu, 21 Jul 2005 14:41:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvfh5-0001xG-6k for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:22:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24050 for ; Thu, 21 Jul 2005 14:22:49 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgB9-0002ld-DI for rfid@ietf.org; Thu, 21 Jul 2005 14:53:56 -0400 Received: from ([10.100.101.65]) by relay1.manh.com with ESMTP id 4029082.14740910; Thu, 21 Jul 2005 14:21:48 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 14:21:52 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 14:21:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 14:21:59 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBE0@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP and SNMP Thread-Index: AcWOHra5UQc4POUGQJmJNtJuCTJxIwAAQUJg From: "Howard Kapustein" To: "Mountain, Highland M" X-OriginalArrivalTime: 21 Jul 2005 18:21:44.0624 (UTC) FILETIME=[0C976300:01C58E21] X-Spam-Score: 0.2 (/) X-Scan-Signature: 96f877a001288d1394c267f7fd902958 X-Mailman-Approved-At: Thu, 21 Jul 2005 14:41:12 -0400 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0373372337==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0373372337== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E21.158BD4E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E21.158BD4E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Once an SNMP manager receives a trap relating to the above, would it not be useful to at least *view* relevant >RFID related operational/configuration info through an RFID reader MIB to aid in diagnosing the problem.=20 =20 One would think, which is one example why it's hard to cleanly divorce "configuration" from "management". OTOH, taking the previous example further, HTTP defines how you interoperate with a web server, doesn't say anything about managing the web server, but DOES refer to configuration-related elements, e.g. URLs. Hard for an operational system to be totally divorced from at least some key aspects of "configuration". =20 How do Warehouse Management systems handle device faults and troubleshooting? Depends on the system, but generally they consume and produce 'operational data' and management facilities handle 'management data'. WM can get notified a box just rolled down a conveyor, but typically wouldn't know or care that the conveyor is overheating (or whatever). =20 Is their a notion of traps/alerts in these systems? Not in this level of conversation. Ever hear of a Warehouse Control System? WCS? Semi-common term for 'communication system that on the left side deals with material handling equipment (MHE) like automated sorters and conveyors, and on the right side deals with applications interested in exchanging information them'. So yeah, it's a sexy high falutin' term, but a WCS is basically a communication subsystem. Not universally common, there's lots of point-to-point interaction among other things, but that's one scenario some may be familiar with. =20 In that picture, I think SLRRP targets the 'left' side of that picture - MHE<->WCS In the WCS/MHE world, there are no common standards that I'm aware of. De facto standards sure, e.g. you could safely call the Siemens-Diematic(sp?) WCS interface exposed to applications a 'de facto standard'. But I'm not aware of any 'formal' (standards body) standards for such things (not any significant ones). And it's even more diverse on the other side. A standard protocol exposed by automated sorters or other MHE equipment? Hahahahaha... =20 - Howard =20 ________________________________ From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]=20 Sent: Thursday, July 21, 2005 2:05 PM To: Howard Kapustein Cc: Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 =20 >>One can look at other device classes and see device operations outside of network operations captured by standard MIBs. >>Take the printer mib for example. =20 >Yes, very true. >>Good, at least we agree on something. >But SNMP doesn't fit very well for operational behaviors (reading/writing/killing), for a variety of reasons. =20 Right, I never proposed SNMP should be used for such operational behaviors, nor did I say the Printer MIB promotes printing docs through SNMP. What I see is the usefulness of the data being discussed in SLRRP within SNMP. =20 Are you promoting SNMP=3D *management* using only those well known mibs which have gone before (MIB-2, HOST-RESOURCES) without the potential of new MIBs in the RFID reader space? =20 =20 Let me rephrase one of my original statements: =20 But if the tags are not passing through the reader, because there is a problem with the Reader, then the reader is not working and someone should be notified to fix it ~ SNMP issue with an RFID twist? =20 =20 Once an SNMP manager receives a trap relating to the above, would it not be useful to at least *view* relevant RFID related operational/configuration info through an RFID reader MIB to aid in diagnosing the problem. Data like Antenna Configuration, Reader Capabilities, and General tag read statistics could be useful in some cases. =20 =20 How do Warehouse Management systems handle device faults and troubleshooting? Is their a notion of traps/alerts in these systems? =20 =20 =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 9:41 AM To: Mountain, Highland M; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 >But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? If the reader reports no tags, is that because the reader's broken, the tags are broken, or there really are no tags to read? =20 I'd expect 0 tag reads for a reader monitoring a dock door if nothing goes thru the dock door. =20 =20 >Is there not potential for some overlap here? No. Take a reader with a wire to the antenna and fry the antenna, where the reader will power up but the antenna won't work. Some readers have no built-in diagnostics and will blithely run, never reading anything from that antenna. =20 Or even better, bake in diagnostics but now have a *partially* working antenna, only working at, say, half the expected range/power/whatever. =20 SNMP is designed for such use cases. =20 The *consumers* of the data is very different. Management vs. Operation data. Management vs. Operation systems. =20 Tivoli cares about very different events and information than Warehouse Management systems. =20 =20 There's some overlap between "management" and "configuration" (where the latter can be viewed as a subset of the former), but pragmatically you can't divorce "configuration" from the operations side of the system. [Well, you can, but it creates other headaches.] =20 The use cases and issues surrounding "management" and "operations" are different, hence the reason SNMP may be a strong candidate for the former (well, the SNMP protocol plus some MIBs), but a poor option for the latter. =20 =20 FYI there's enough of a delta here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; RP 1.0's goal was "Reading, Writing and Killing tags, and operations needed to support that" vs. RM 1.0's goal was (loosely stated) "managing readers". =20 That said, the RP+RM workgroups had a lot of overlap, and frequently collaborated to varying degrees to jointly design solutions. =20 =20 >One can look at other device classes and see device operations outside of network operations captured by standard MIBs. >Take the printer mib for example. =20 Yes, very true. But SNMP doesn't fit very well for operational behaviors (reading/writing/killing), for a variety of reasons. Certainly you -could- use SNMP to read tag info from a reader, but it's not a good option. Do *you* know of any application that uses SNMP to print a document on a printer, instead of a "print" api/protocol?=20 =20 =20 =20 Here's a simpler way to think of your original question: Change "RFID reader" + "SLRRP" to "web server" + "HTTP". =20 Can you please compare HTTP and SNMP in their intentions? =20 - Howard =20 =20 ________________________________ From: Mountain, Highland M [mailto:highland.m.mountain@intel.com]=20 Sent: Thursday, July 21, 2005 12:18 PM To: Howard Kapustein; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 Howard wrote>SNMP targets questions like "how do I know the reader is working" =20 But if the tags are not passing through the reader, then the reader is not working ~ SNMP issue with an RFID twist? Is there not potential for some overlap here? =20 Howard wrote> SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 One can look at other device classes and see device operations outside of network operations captured by standard MIBs. Take the printer mib for example. =20 =20 Thoughts? =20 Highland Mary Mountain =20 (480) 552-3817 ________________________________ From: Howard Kapustein [mailto:hkapustein@manh.com]=20 Sent: Thursday, July 21, 2005 6:26 AM To: Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP =20 One delta: =20 SNMP =3D management SLRRP =3D operations =20 SNMP =3D *management* of network 'things' (not merely one type of = device)=20 SLRRP =3D *operational* processing of rfid network readers =20 SLRRP targets questions like "how do I know what tags are passing by a reader" SNMP targets questions like "how do I know the reader is working" =20 Things like Tivoli/OpenView/... care about the latter. Things like warehouse management systems care about the former. =20 - Howard =20 ________________________________ From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 8:28 AM To: rfid@ietf.org Subject: [Rfid] SLRRP and SNMP =20 =20 Can anyone please compare SLRRP and SNMP in their intentions? =20 =20 Thanks, Gustavo Frederico Allstream =20 =20 ------_=_NextPart_001_01C58E21.158BD4E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Once an SNMP manager receives a = trap relating to the above, would it not be useful to at least *view* = relevant

>RFID related = operational/configuration info through an RFID reader MIB to aid in diagnosing the = problem. 

 

One would think, which is one = example why it’s hard to cleanly divorce “configuration” from = “management”.

OTOH, taking the previous example = further, HTTP defines how you interoperate with a web server, doesn’t say = anything about managing the web server, but DOES refer to configuration-related elements, e.g. URLs. Hard for an operational system to be totally = divorced from at least some key aspects of = “configuration”.

 

How do Warehouse Management systems handle device faults and = troubleshooting?

Depends on the system, but = generally they consume and produce ‘operational data’ and management = facilities handle ‘management data’.

WM can get notified a box just = rolled down a conveyor, but typically wouldn’t know or care that the conveyor = is overheating (or whatever).

 

Is their a notion of traps/alerts in these = systems?

Not in this level of = conversation.

Ever hear of a Warehouse Control = System? WCS?

Semi-common term for = ‘communication system that on the left side deals with material handling equipment = (MHE) like automated sorters and conveyors, and on the right side deals with = applications interested in exchanging information = them’.

So yeah, it’s a sexy high = falutin’ term, but a WCS is basically a communication = subsystem.

Not universally common, = there’s lots of point-to-point interaction among other things, but that’s one = scenario some may be familiar with.

 

In that picture, I think SLRRP = targets the ‘left’ side of that picture – = MHE<->WCS

In the WCS/MHE world, there are no = common standards that I’m aware of.

De facto standards sure, e.g. you = could safely call the Siemens-Diematic(sp?) WCS interface exposed to = applications a ‘de facto standard’.

But I’m not aware of any = ‘formal’ (standards body) standards for such things (not any significant = ones).

And it’s even more diverse on = the other side.

A standard protocol exposed by = automated sorters or other MHE equipment?

Hahahahaha…<= /font>

 

      =       - Howard

 

From: = Mountain, Highland M [mailto:highland.m.mountain@intel.com]
Sent: Thursday, July 21, = 2005 2:05 PM
To: Howard Kapustein
Cc: Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

 

>>One can look at other device classes and see device operations outside of = network operations captured by standard MIBs.

>>Take the printer mib for example. 

>Yes, very true.  = >>Good, at least we agree on something.

>But SNMP doesn’t fit very = well for operational behaviors (reading/writing/killing), for a variety of = reasons.

 

Right, I never proposed SNMP should = be used for such operational behaviors, nor did I say the Printer MIB = promotes printing docs through SNMP.  What I see is the usefulness of the data being discussed in SLRRP within SNMP.

 

Are you promoting SNMP=3D *management* using only those well = known mibs which have gone before (MIB-2, HOST-RESOURCES) without the = potential of new MIBs in the RFID reader space?

 

 

Let me rephrase one of my original statements:

 

But if the tags are not passing = through the reader, because there is a = problem with the Reader, then the reader is not working and someone should = be notified to fix it ~ SNMP issue with an RFID twist?  =

 

Once an SNMP manager receives a = trap relating to the above, would it not be useful to at least *view* relevant RFID related operational/configuration info through an RFID reader MIB to aid in = diagnosing the problem.  Data like Antenna Configuration, Reader Capabilities, = and General tag read statistics could be useful in some cases.  =

 

How do Warehouse Management systems = handle device faults and troubleshooting?  Is their a notion of = traps/alerts in these systems?

 

 

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 9:41 AM
To: Mountain, Highland M; Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

>But if the tags are not passing through the reader, then the reader is not = working ~ SNMP issue with an RFID twist?

If the reader reports no tags, is = that because the reader’s broken, the tags are broken, or there really = are no tags to read?

 

I’d expect 0 tag reads for a = reader monitoring a dock door if nothing goes thru the dock = door.

 

 

>Is there not potential for some overlap = here?

No.

Take a reader with a wire to the = antenna and fry the antenna, where the reader will power up but the antenna = won’t work. Some readers have no built-in diagnostics and will blithely run, = never reading anything from that antenna.

 

Or even better, bake in diagnostics = but now have a *partially* = working antenna, only working at, say, half the expected = range/power/whatever.

 

SNMP is designed for such use = cases.

 

The *consumers* of the data is very different.

Management vs. Operation = data.

Management vs. Operation = systems.

 

Tivoli cares about very different events and information than = Warehouse Management systems.

 

 

There’s some overlap between “management” and “configuration” (where the = latter can be viewed as a subset of the former), but pragmatically you can’t = divorce “configuration” from the operations side of the system. = [Well, you can, but it creates other headaches.]

 

The use cases and issues = surrounding “management” and “operations” are different, = hence the reason SNMP may be a strong candidate for the former (well, the SNMP = protocol plus some MIBs), but a poor option for the = latter.

 

 

FYI there’s enough of a delta = here that EPCglobal has 2 workgroups, Reader Protocol and Reader Management; = RP 1.0’s goal was “Reading, Writing and Killing tags, and = operations needed to support that” vs. RM 1.0’s goal was (loosely = stated) “managing readers”.

 

That said, the RP+RM workgroups had = a lot of overlap, and frequently collaborated to varying degrees to jointly = design solutions.

 

 

>One can look at other device classes and see device operations outside of = network operations captured by standard MIBs.

>Take the printer mib for example. 

Yes, very = true.

But SNMP doesn’t fit very = well for operational behaviors (reading/writing/killing), for a variety of = reasons.

Certainly you -could- use SNMP to = read tag info from a reader, but it’s not a good = option.

Do *you* know of any application that uses SNMP to print a document on a printer, instead of a “print” api/protocol? =

 

 

 

Here’s a simpler way to think = of your original question:

Change “RFID reader” + “SLRRP” to “web server” + = “HTTP”.

 

Can you please compare HTTP and = SNMP in their intentions?

 

      =       - Howard

 

 

From: = Mountain, Highland M [mailto:highland.m.mountain@intel.com]
Sent: Thursday, July 21, = 2005 12:18 PM
To: Howard Kapustein; = Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

Howard wrote>SNMP targets = questions like “how do I know the reader is = working”

 

But if the tags are not passing = through the reader, then the reader is not working ~ SNMP issue with an RFID twist?  Is there not potential for some overlap = here?

 

Howard = wrote>

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

One can look at other device = classes and see device operations outside of network operations captured by standard MIBs.  Take the printer mib for example.  =

 

Thoughts?

 

Highland Mary = Mountain

 

=

(480) = 552-3817

From: = Howard Kapustein [mailto:hkapustein@manh.com]
Sent: Thursday, July 21, = 2005 6:26 AM
To: Frederico, Gustavo; rfid@ietf.org
Subject: RE: [Rfid] SLRRP = and SNMP

 

One = delta:

 

SNMP =3D = management

SLRRP =3D = operations

 

SNMP =3D *management* of network ‘things’ (not merely one type of device) =

SLRRP =3D *operational* processing of rfid network readers

 

SLRRP targets questions like = “how do I know what tags are passing by a = reader”

SNMP targets questions like = “how do I know the reader is working”

 

Things like Tivoli/OpenView/… = care about the latter.

Things like warehouse management = systems care about the former.

 

      =       - Howard

 

From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] = On Behalf Of Frederico, = Gustavo
Sent: Thursday, July 21, = 2005 8:28 AM
To: rfid@ietf.org
Subject: [Rfid] SLRRP and = SNMP

 

 

Can anyone please compare SLRRP and = SNMP in their intentions?

 

 

Thanks,

=

Gustavo Frederico

Allstream

 

 

------_=_NextPart_001_01C58E21.158BD4E7-- --===============0373372337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0373372337==-- From rfid-bounces@lists.ietf.org Thu Jul 21 14:56:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgDv-0000mm-IK; Thu, 21 Jul 2005 14:56:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgDr-0000k0-Vu for rfid@megatron.ietf.org; Thu, 21 Jul 2005 14:56:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27843 for ; Thu, 21 Jul 2005 14:56:42 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvghw-0005Cr-Lw for rfid@ietf.org; Thu, 21 Jul 2005 15:27:49 -0400 Received: from ([10.100.101.65]) by relay1.manh.com with ESMTP id 4029082.14744126; Thu, 21 Jul 2005 14:55:41 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 14:55:42 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 14:55:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] SLRRP and SNMP Date: Thu, 21 Jul 2005 14:55:38 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBE2@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP and SNMP Thread-Index: AcWOIzXjMe71LXv/T42QArhXdLj38wAAeLcg From: "Howard Kapustein" To: "Margaret Wasserman" , "Mountain, Highland M" , "Frederico, Gustavo" , X-OriginalArrivalTime: 21 Jul 2005 18:55:29.0206 (UTC) FILETIME=[C3561560:01C58E25] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Yes, very valid. My point wasn't to say "0 tag reads =3D no data", but to point out how 'operational' and 'management' systems have very different interests and worldviews, though often overlapping to varying degrees. - Howard P.S. EPCglobal's Reader Management defines an SNMP binding, because that makes sense. OTOH, Reader Protocol 1.1 has no SNMP-based binding for equally inversely sensible reasons. I forget the exact IETF specs referenced by RM 1.0 (SNMP + MIB(s), among other things), but the spec's LCWD so EPCglobal members can peruse it at their leisure. I guess non-EPCglobal members will have to wait until the public (internet) posting to satisfy their curiosity. -----Original Message----- From: Margaret Wasserman [mailto:margaret@thingmagic.com]=20 Sent: Thursday, July 21, 2005 2:33 PM To: Howard Kapustein; Mountain, Highland M; Frederico, Gustavo; rfid@ietf.org Subject: RE: [Rfid] SLRRP and SNMP At 12:40 PM -0400 7/21/05, Howard Kapustein wrote: >But if the tags are not passing through the reader, then the reader=20 >is not working ~ SNMP issue with an RFID twist? If the reader reports no tags, is that because the reader's broken,=20 the tags are broken, or there really are no tags to read? I'd expect 0 tag reads for a reader monitoring a dock door if nothing=20 goes thru the dock door. I actually think that there will be people who want to monitor a=20 count of the tag reads performed by a reader, or on a particular=20 antenna. If there is a counter available for that purpose, it can also be used=20 for threshhold alarms -- turn the reader icon red if it hasn't read=20 any tags in the past 10 minutes, for example. When combined with other sensors (electric eyes, sensors that detect=20 when doors are open, motion sensors, etc.), it might also be possible=20 to generate a more serious alarm if the reader should be reading=20 tags, but isn't (i.e. when items are passing by and/or the door is=20 open). I would consider all of those items to fall under management or=20 monitoring, and I think that SNMP is a better technology for that=20 purpose than a proprietary protocol. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 15:09:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgQJ-0007o9-Cq; Thu, 21 Jul 2005 15:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvgQI-0007mm-KR for rfid@megatron.ietf.org; Thu, 21 Jul 2005 15:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29613 for ; Thu, 21 Jul 2005 15:09:33 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvguN-0006Bq-Dq for rfid@ietf.org; Thu, 21 Jul 2005 15:40:40 -0400 Received: from ([10.100.101.65]) by relay1.manh.com with ESMTP id 4029082.14745276; Thu, 21 Jul 2005 15:08:34 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Thu, 21 Jul 2005 15:08:27 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 15:08:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] SLRRP -> RRCP? Date: Thu, 21 Jul 2005 15:08:31 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBE7@ma-atl57.us.manh.com> Thread-Topic: [Rfid] SLRRP -> RRCP? Thread-Index: AcWN7B+24TvIUCRYRXqaeqO+7qw+MwAG3uXQAAXg2fAAAM8usAABSRNQ From: "Howard Kapustein" To: "David Husak" X-OriginalArrivalTime: 21 Jul 2005 19:08:32.0962 (UTC) FILETIME=[967DC220:01C58E27] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org I was wondering how many people would notice :-) -----Original Message----- From: David Husak [mailto:dhusak@revasystems.com]=20 Sent: Thursday, July 21, 2005 2:34 PM To: Howard Kapustein Cc: rfid@ietf.org Subject: RE: [Rfid] SLRRP -> RRCP? Howard,=20 Remember, it's important to take the date of an RFC into consideration when evaluating its merits:) Dave ------------------------ David J. Husak Reva Systems Corporation dhusak@revasystems.com > -----Original Message----- > From: Howard Kapustein [mailto:hkapustein@manh.com] > Sent: Thursday, July 21, 2005 2:12 PM > To: David Husak; Marshall Rose > Cc: rfid@ietf.org > Subject: RE: [Rfid] SLRRP -> RRCP? >=20 > >The trailing 'P' has always > >struck me as sort-of redundant or implied, since you'll typically hear > >people say things like "... the XXXXP protocol." >=20 > But not unprecedented. > For instance, HyperText Transport Protocol has had some middling > success... >=20 > Not that I'm suggesting one way or the other, just that XXXXP isn't > necessarily bad. >=20 > - Howard >=20 > P.S. Google for "rfc http hyper" and guess the 1st hit > http://www.faqs.org/rfcs/rfc2324.html > Another example of XXXXP >=20 > Also an example that truly anyone can get anything proposed as an > Internet-Draft :-> >=20 >=20 > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] > On Behalf Of David Husak > Sent: Thursday, July 21, 2005 12:31 PM > To: Marshall Rose > Cc: rfid@ietf.org > Subject: RE: [Rfid] SLRRP -> RRCP? >=20 >=20 > For the record, the protocol was Simple, the reader was Lightweight:) >=20 > If we've run afoul of current naming practice, I'm all for changing the > name now. We've already built some name equity for SLRRP (I will admit > that's entirely due to the provocative pronunciation), but if change is > inevitable, the sooner, the better. >=20 > I'm fine with RCP or RRCP... I'd also put R2CP, or even just R2C, in the > mix. It can have the double meaning of R-squared-C =3D RRC for RFID Reader > Control, as well as "Reader-to-Controller". The trailing 'P' has always > struck me as sort-of redundant or implied, since you'll typically hear > people say things like "... the XXXXP protocol." >=20 > Any other candidates out there? >=20 > Dave >=20 >=20 > ------------------------ > David J. Husak > Reva Systems Corporation > dhusak@revasystems.com >=20 > > -----Original Message----- > > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] > On > > Behalf Of Marshall Rose > > Sent: Thursday, July 21, 2005 1:38 AM > > To: P. Krishna > > Cc: rfid@ietf.org > > Subject: Re: [Rfid] SLRRP -> RRCP? > > > > i think margaret raises a valid point, or more accurately two points: > > first, is that it's likely that the name will get changed; and, > > second, that it's probably better to change it earlier tather than > > later. > > > > i think it's reasonable to start worrying about this now... ideally, > > i'd like to see a new name in the charter when it's approved! > > > > /mtr > > > > > > > > > > _______________________________________________ > > Rfid mailing list > > Rfid@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/rfid >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 15:54:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh7k-0003Ow-OK; Thu, 21 Jul 2005 15:54:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh7f-0003IJ-5a for rfid@megatron.ietf.org; Thu, 21 Jul 2005 15:54:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04684 for ; Thu, 21 Jul 2005 15:54:18 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvhbf-0000vw-QB for rfid@ietf.org; Thu, 21 Jul 2005 16:25:27 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 15:53:58 -0400 Subject: RE: [Rfid] SLRRP and SNMP From: Scott Barvick To: Howard Kapustein In-Reply-To: <02254DCB1D0B2340B8D1D54E770CAE76DAEBE2@ma-atl57.us.manh.com> References: <02254DCB1D0B2340B8D1D54E770CAE76DAEBE2@ma-atl57.us.manh.com> Content-Type: text/plain Message-Id: <1121975639.2997.1193.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Jul 2005 15:53:59 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jul 2005 19:53:58.0286 (UTC) FILETIME=[EEE932E0:01C58E2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org, "Mountain, Highland M" X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org I think we are in violent agreement on the general need for a basic RFID reader MIB. The proposed charter for the CAIRO WG: http://www1.ietf.org/mail-archive/web/rfid/current/msg00159.html describes efforts following completion of SLRRP to work on device monitoring among other things. To me, a MIB is a one of those efforts, and that MIB would have the type of information that is being discussed. And, before anyone jumps on me :), note that the last paragraph in the list of futures for the CAIRO WG says that it is possible that work (e.g. a MIB) developed in other groups could be simply referenced if that is what the group wants to do. Scott On Thu, 2005-07-21 at 14:55, Howard Kapustein wrote: > Yes, very valid. > > My point wasn't to say "0 tag reads = no data", but to point out how > 'operational' and 'management' systems have very different interests and > worldviews, though often overlapping to varying degrees. > > - Howard > > P.S. EPCglobal's Reader Management defines an SNMP binding, because that > makes sense. OTOH, Reader Protocol 1.1 has no SNMP-based binding for > equally inversely sensible reasons. > > I forget the exact IETF specs referenced by RM 1.0 (SNMP + MIB(s), among > other things), but the spec's LCWD so EPCglobal members can peruse it at > their leisure. I guess non-EPCglobal members will have to wait until the > public (internet) posting to satisfy their curiosity. > > > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret@thingmagic.com] > Sent: Thursday, July 21, 2005 2:33 PM > To: Howard Kapustein; Mountain, Highland M; Frederico, Gustavo; > rfid@ietf.org > Subject: RE: [Rfid] SLRRP and SNMP > > At 12:40 PM -0400 7/21/05, Howard Kapustein wrote: > >But if the tags are not passing through the reader, then the reader > >is not working ~ SNMP issue with an RFID twist? > If the reader reports no tags, is that because the reader's broken, > the tags are broken, or there really are no tags to read? > > I'd expect 0 tag reads for a reader monitoring a dock door if nothing > goes thru the dock door. > > > I actually think that there will be people who want to monitor a > count of the tag reads performed by a reader, or on a particular > antenna. > > If there is a counter available for that purpose, it can also be used > for threshhold alarms -- turn the reader icon red if it hasn't read > any tags in the past 10 minutes, for example. > > When combined with other sensors (electric eyes, sensors that detect > when doors are open, motion sensors, etc.), it might also be possible > to generate a more serious alarm if the reader should be reading > tags, but isn't (i.e. when items are passing by and/or the door is > open). > > I would consider all of those items to fall under management or > monitoring, and I think that SNMP is a better technology for that > purpose than a proprietary protocol. > > Margaret > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 18:44:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvjm8-00023v-Uh; Thu, 21 Jul 2005 18:44:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvjm5-00023k-OD for rfid@megatron.ietf.org; Thu, 21 Jul 2005 18:44:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22198 for ; Thu, 21 Jul 2005 18:44:15 -0400 (EDT) From: Rob.Buck@intermec.com Received: from agate.intermec.com ([63.127.92.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvkGC-0005rl-1a for rfid@ietf.org; Thu, 21 Jul 2005 19:15:25 -0400 Received: by normail.norand.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Jul 2005 17:44:16 -0500 Message-ID: <49E558014BABD711AA980002A5421C990767AA29@normail.norand.com> To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Thu, 21 Jul 2005 17:44:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org FYI: I view SLRRP/binary or SLRRP/text(non-XML) as a viable protocol that can be adapted to a serial device. However, I wouldn't try to put SLRRP/XML on a serial device. I realize that SLRRP is intended to be a network protocol. However, in my evaluation of SLRRP I'm factoring in legacy serial devices I want to support. A serial adaptation of SLRRP will be required if I adopt SLRRP. Rob -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Frederico, Gustavo Sent: Thursday, July 21, 2005 7:55 AM To: rfid@ietf.org Subject: RE: [Rfid] XML vs. Text vs. Binary XML is already the de facto standard for interaction between disparate systems. That is clear to people that work in software and systems integration. Perhaps it's not so obvious to folks that work mostly with hardware. I would be concerned to used a protocol that is not XML-based and defines software interface. The size of XML does not have to be so much of a concern. It will probably be x % of what it would be if it were not XML-based anyway. The human-readability of XML is not a problem either, with a plethora of XML tools that facilitate editing and generation. There are lots of packages for parsing in Java, Perl and .NET compact framework. There's NanoXML, for instance, a light-weight Java xml parser that requires 6K. There is work on W3C on a binary representation of XML ( http://www.w3.org/XML/Binary/ ), but it doesn't seem to be finalized, and maybe it isn't necessary in this case either. XML brings many benefits that are well-documented. What the group may also consider is the use of RDF or OWL-Lite, for strong semantics and scalability, that I think would fit configuration management very well. Regards, Gustavo Frederico Allstream -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Margaret Wasserman Sent: Wednesday, July 20, 2005 10:19 PM To: rfid@ietf.org Subject: [Rfid] XML vs. Text vs. Binary We've had some discussion on this list about XML encoding vs. binary encoding... I'm not sure that we are in agreement on all of the related points, but the concerns with XML seem to be code size on the reader and protocol overhead on the wire. These concerns can be minimized by the use of a restricted XML subset, such as canonical XML (see RFC 3076). However, there still seem to be some concerns along those lines. The only advantages that I remember being discussed for a binary encoding were the complement to the concerns with XML: smaller code size on the reader and less protocol overhead. I think, though, that our discussions have missed a major benefit of any text-based encoding (whether a protocol-specific text encoding or canonical XML): the ability to access the device using text processing tools (such as Perl scripts) and/or for a human to interact with the device directly. In 2002, the IAB held a Network Management workshop that is documented in RFC 3535. I would suggest that folks on this list read this report which can be found at: http://www.ietf.org/rfc/rfc3535.txt?number=3535 One of the interesting findings of that workshop was that one of the significant barriers to the use of SNMP as a configuration or control protocol is that it uses a binary encoding, which means that SNMP-specific client software (an SNMP browser or manager) is needed to interact with the device via SNMP. This prevents SNMP access using text processing tools or via human interaction. I would not like to see the industry create the same problem with an RFID control protocol. If there is real evidence that canonical XML would require too much code size on the reader and/or would result in an unacceptable level of protocol overhead, perhaps we could consider a protocol-specific text-based encoding (similar to FTP, SMTP and HTTP)? I don't believe that parsing a well-defined text-based encoding would require much more code than processing a binary encoding. And, in some cases a text based encoding would actually result in less data on the wire -- for instance a 32 bit integer with the value of 3 would be encoded in one byte of text ("3"), while it would require 4 bytes in binary encoding ("0x00000003'). Personally I like canonical XML, because I think it strikes a good balance between being human readable and machine-parsable. I also like the fact that the syntax is already well-defined. However, I think that well-defined, protocol-specific textual encodings could also achieve that balance, perhaps with less impact in the areas of concern (code size and protocol overhead). What do others think? Should we at least consider a text-based encoding? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid "This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited." _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 19:56:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkuB-0005sW-TA; Thu, 21 Jul 2005 19:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvkuA-0005sR-Tf for rfid@megatron.ietf.org; Thu, 21 Jul 2005 19:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03475 for ; Thu, 21 Jul 2005 19:56:39 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvlOG-0003TQ-UT for rfid@ietf.org; Thu, 21 Jul 2005 20:27:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Thu, 21 Jul 2005 19:56:22 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWNmsKEQ+QL96zVRH6n9Xw+kxqyKgAdu9WQ From: "David Husak" To: "Margaret Wasserman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org First of all, let me say that I have no axe to grind wrt a text (I'll lump XML into this category for now) vs. a binary protocol. I just want a solution that's simple, unambiguous and efficient-enough to be implemented on a lightweight reader. That said, I do think that there are important factors to consider apart from the code-size and protocol-overhead-on-the-wire issues*: 1. Direct-access vs. TLV-binary vs. sequential-text-parsing.=20 In a compact, fixed binary encoding, it's easy for an implementation to access protocol fields directly via indexed load and store, i.e. an implementation need only access the bytes it needs, and it knows where those bytes are.=20 In a type-length-value binary encoding, an implementation can hop from parameter to parameter by accessing only the parameter type and length bytes.=20 A text-based encoding, where parameters are typically delimited by special character sequences, requires accessing all bytes until you find the parameter of interest. ** I apologize for the pedagoguery of the foregoing, but I wanted to illustrate the fact that the amount of processing and attendant latency and latency-variation in generating and interpreting these messages can vary considerably (from a few instructions to a few thousand instructions) depending on the approach chosen. I'll suggest that the latency variation incurred by a text-based encoding, especially on a modest processor, is a real problem in the context of a protocol, like SLRRP, with real-time control requirements. For SLRRP, we chose the TLV-binary approach as the best compromise between flexibility and efficiency.=20 2. Utility of human-readability in the context of SLRRP. I'll grant that for application protocols like FTP, there's real utility in having an encoding that's human-readable and -usable, because it's reasonable to expect a human or equivalent may regularly exercise the protocol, and may need to do so with readily-available tools. (Though, even in those cases the protocol is front-ended by a CLI that has a help facility, etc.) I think that the likelihood of SLRRP being successfully used in this manner is very close to zero, due to the sub-second real-time nature of the task-at-hand (reading tags in a dynamic environment) at the layer-at-hand. One must also recognize that a large fraction of the parameters that are controlled in SLRRP are not numbers, they are selectors or enumerated types, which makes it even less likely that an engineer typing UTF-8 SLRRP commands over a telnet connection can get it right without some help/cheat-sheets/tools, in which case the value of the text encoding is diminished. One could argue that human-readability might be useful for debugging during product development, early trials, etc. Maybe, but you'll probably have or want a SLRRP codec for your sniffer in the lab anyway...=20 Another advantage of a text-based encoding that's generally acknowledged is the possibility of using text-editing tools to manipulate and compare the protocol contents, usually in the context of configuration models that permit bulk dumps and restores of configuration info. This advantage also does not seem to apply in the present case. Net of all of that, in the present case, I just don't see that the benefit of human-readability outweighs the cost. 3. Other layers Which brings me to an important point, which is that many of the text-based encoding advantages do indeed apply at higher-layers, for example the ALE layer in the EPCglobal framework. Text-based encoding is almost certainly the right choice at that level of abstraction, on up. 4. Management and configuration interface At the risk of crossing the streams, it's important to recognize that SLRRP is not a management and configuration protocol. It is a control and data transport protocol for a real-time data acquisition device. The requirements and the correct choice of encoding may/will vary when we consider the two functions. It may well be the case that we decide that the right choice for the management or configuration interface at the SLRRP level is text-based, and therefore we've already got the text- or XML-parser, so, modulo the performance impact, we should just use it for the SLRRP path as well. Maybe. BTW, RFC3535 is a good read and appears to be quite comprehensive and compact. Though, I'll point out the fact that SNMP creates the requirement for specific client applications, was rated a 'neutral' by the task force, and was not characterized as a "significant barrier" to its use. There are, of course a number of well-understood SNMP 'minuses,' but this isn't one of them. I must say, that based on the cursory description in RFC3535, COPS-PR seems like it has some really interesting properties for managing RFID reader networks. Unfortunately, it seems like, at least as of May 2003, it had an uncertain future. Dave ---------------------------- *I agree that these are non-issues. Memory is really cheap. And the only thing cheaper than memory is bandwidth in an enterprise LAN. **As an aside, the example of encoding the number '3' being more efficient in text vs. as 32-bit integer is a bit specious. Obviously, if you've allocated 32-bits to the field, you're also probably interested in expressing numbers with more than four digits, in which case the binary encoding is more compact... even before accounting for the fact that the text-encoded '3' really looks something like startdelimiter+parameterID+'3'+enddelimiter. ------------------------ David J. Husak Reva Systems Corporation dhusak@revasystems.com > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Margaret Wasserman > Sent: Wednesday, July 20, 2005 10:19 PM > To: rfid@ietf.org > Subject: [Rfid] XML vs. Text vs. Binary >=20 >=20 > We've had some discussion on this list about XML encoding vs. binary > encoding... >=20 > I'm not sure that we are in agreement on all of the related points, > but the concerns with XML seem to be code size on the reader and > protocol overhead on the wire. These concerns can be minimized by > the use of a restricted XML subset, such as canonical XML (see RFC > 3076). However, there still seem to be some concerns along those > lines. >=20 > The only advantages that I remember being discussed for a binary > encoding were the complement to the concerns with XML: smaller code > size on the reader and less protocol overhead. >=20 > I think, though, that our discussions have missed a major benefit of > any text-based encoding (whether a protocol-specific text encoding or > canonical XML): the ability to access the device using text > processing tools (such as Perl scripts) and/or for a human to > interact with the device directly. >=20 > In 2002, the IAB held a Network Management workshop that is > documented in RFC 3535. I would suggest that folks on this list read > this report which can be found at: >=20 > http://www.ietf.org/rfc/rfc3535.txt?number=3D3535 >=20 > One of the interesting findings of that workshop was that one of the > significant barriers to the use of SNMP as a configuration or control > protocol is that it uses a binary encoding, which means that > SNMP-specific client software (an SNMP browser or manager) is needed > to interact with the device via SNMP. This prevents SNMP access > using text processing tools or via human interaction. >=20 > I would not like to see the industry create the same problem with an > RFID control protocol. >=20 > If there is real evidence that canonical XML would require too much > code size on the reader and/or would result in an unacceptable level > of protocol overhead, perhaps we could consider a protocol-specific > text-based encoding (similar to FTP, SMTP and HTTP)? I don't believe > that parsing a well-defined text-based encoding would require much > more code than processing a binary encoding. And, in some cases a > text based encoding would actually result in less data on the wire -- > for instance a 32 bit integer with the value of 3 would be encoded in > one byte of text ("3"), while it would require 4 bytes in binary > encoding ("0x00000003'). >=20 > Personally I like canonical XML, because I think it strikes a good > balance between being human readable and machine-parsable. I also > like the fact that the syntax is already well-defined. However, I > think that well-defined, protocol-specific textual encodings could > also achieve that balance, perhaps with less impact in the areas of > concern (code size and protocol overhead). >=20 > What do others think? Should we at least consider a text-based encoding? >=20 > Margaret >=20 >=20 >=20 > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 21:05:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvlyk-00086g-Kg; Thu, 21 Jul 2005 21:05:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvlyi-000822-Mb for rfid@megatron.ietf.org; Thu, 21 Jul 2005 21:05:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07947 for ; Thu, 21 Jul 2005 21:05:27 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvmSp-0007La-4N for rfid@ietf.org; Thu, 21 Jul 2005 21:36:37 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 447859; Thu, 21 Jul 2005 20:59:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Date: Thu, 21 Jul 2005 21:05:10 -0400 To: "David Husak" , From: Margaret Wasserman Subject: RE: [Rfid] XML vs. Text vs. Binary Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi David, At 7:56 PM -0400 7/21/05, David Husak wrote: >I'll suggest that the >latency variation incurred by a text-based encoding, especially on a >modest processor, is a real problem in the context of a protocol, like >SLRRP, with real-time control requirements. We've been around this block before, but without reaching a clear answer. What are the real-time requirements for RFID reader control/management? And, what are the minimum system requirements that we need to consider? If we can't answer this for the entire industry, I think we at least need to reach a mutual understanding of the range of devices that we are planning to support with this protocol. The stringency of the real-time requirements, and whether they exist at all, may be a function of the paradigm that we use for reader control/management. As I stated in my earlier message, I would prefer a paradigm where a reader operates autonomously based on configured filters and policies, similar to an IP switch or router. I think that such a paradigm would be much more practical, much more scalable and much more in-line with the RFID reader applications I've seen, than a scenario where a large set of readers are micro-managed on a real-time basis by a centralized network controller. Most of your real-time and scaling requirements seem to derive from your fundamental assumption that there will be a single controller providing real-time control for 1000's of readers, and I see no reason to build our protocol (or an RFID network) so that a single real-time controller is necessary in large-scale installations. >At the risk of crossing the streams, it's important to recognize that >SLRRP is not a management and configuration protocol. It is a control >and data transport protocol for a real-time data acquisition device. If this is the case, why do you believe that the IETF has any special expertise to offer here? We don't have any experience (that I'm aware of, anyway) in developing real-time control protocols for data acquisition devices (although I'm sure that someone has used SNMP for this purpose). We generally develop higher-level management and control protocols for devices (almost exclusively network infrastructure devices) that perform their main functions independently based on filters and policies, without consulting a controlling entity in real-time. I think that RFID readers could be controlled and managed at the same level as most networking equipment, perhaps using some of the same mechanisms. You seem to thinks so, too, since you mentioned that COPS-PR could be an interesting solution in this space. IMO, though, it's not consistent to argue that these devices will be controlled and managed like networking equipment (which is the primary argument for why the IETF has any pertinent expertise here), AND to argue that these will be very minimal devices (without enough processing power or memory to deal with a simple text encoding) that will be controlled top-down with all of their real-time decisions made by a network controller. When you add the notion that the data and control may be communicated over a low-bandwidth serial link, you have completely departed from any territory in which the IETF has any special expertise, as far as I know. So, which is it? Regarding the need for specialized clients... I understand that you, as a middleware vendor, prefer a worldview in which people purchase commercial middleware products to access RFID readers (or run substantial open source packages). As a reader vendor, I obviously don't want my product to require a high-priced commercial middleware package to be useful. And, today we certainly see a large number of customers who prefer to write their own clients to access RFID readers, often using text processing languages like Perl, or even shell scripts. Even in installations that use middleware, it could be extremely valuable to access the reader interface directly using test and debugging scripts, in order to determine if there is a reader failure or if the problem lies elsewhere in the system. So, I will restate my opinion that we should not lightly develop an RFID reader management protocol that can only be access from a specialized client. To your point about enumerated types, etc.... There is no reason why a text interface couldn't allow well-defined strings to be used for those enumerations (EPC0, EPC1, EPCG2, etc...), rather than requiring the client (whether it is a piece of middleware, a Perl script or a human typing at an SSH prompt) to send numerical values. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 22:47:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvnZo-0007ZH-4M; Thu, 21 Jul 2005 22:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvnZn-0007ZC-5S for rfid@megatron.ietf.org; Thu, 21 Jul 2005 22:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12808 for ; Thu, 21 Jul 2005 22:47:49 -0400 (EDT) Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvo3w-0003Rv-0n for rfid@ietf.org; Thu, 21 Jul 2005 23:19:01 -0400 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id j6M2jJ5Z032071; Thu, 21 Jul 2005 19:45:20 -0700 In-Reply-To: References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [Rfid] XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 08:17:40 +0530 To: Margaret Wasserman X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org > So, I will restate my opinion that we should not lightly develop an > RFID reader management protocol that can only be access from a > specialized client. i guess we'd need to agree on the meaning of specialized before agreeing on this point. > To your point about enumerated types, etc.... There is no reason > why a text interface couldn't allow well-defined strings to be used > for those enumerations (EPC0, EPC1, EPCG2, etc...), rather than > requiring the client (whether it is a piece of middleware, a Perl > script or a human typing at an SSH prompt) to send numerical values. the problem, i think, is that the XML compromise, like most compromises, doesn't really solve anything; further, like most compromises, it works worse than most purist approaches. it's certainly better than binary if you're going to type-in commands via telnet or ssh. the moment you have to start matching elements, and are typing more than a few of them, you need to have a tool do the typing. as soon as you have tool do it, you've lost the text advantage because it's just as easy for a tool, perl-based or not, to spit out binary as xml. my experience, which admittedly is dated, is that text works for debugging simple protocols like smtp. as soon as you introduce nesting, you lose the type-in advantage. /mtr ps: people who complain about the binary nature of snmp are actually complaining, whether they know it or not, about ASN.1/BER, which define how to describe and encode SNMP packets. i really should have listened more to chuck davin 20 years ago... _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Thu Jul 21 23:59:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvogz-0008TW-Gk; Thu, 21 Jul 2005 23:59:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvogx-0008S7-V1 for rfid@megatron.ietf.org; Thu, 21 Jul 2005 23:59:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18268 for ; Thu, 21 Jul 2005 23:59:17 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvpB5-0007OS-Ss for rfid@ietf.org; Fri, 22 Jul 2005 00:30:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] Supported Reader Paradigms Date: Thu, 21 Jul 2005 23:58:45 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF387@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] Supported Reader Paradigms Thread-Index: AcWOJB6C33oyMVAaTLaEUXMboKTFEwAQkxp/ From: "P. Krishna" To: "Margaret Wasserman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1511056988==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1511056988== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58E71.A8357E47" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58E71.A8357E47 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > IMO, we should think carefully about the extent to which we expect > RFID readers to be controlled in a top-down fashion (receiving > commands from a "controller", whether those commands are immediate or > trigger-based) vs. the extent that we expect readers to be autonomous > and to operate based on configured policies or rules. =20 Supporting a wide range of operational mode of the reader is certainly a goal of SLRRP. If anybody has specific suggestions to augment/modify = some of the=20 commands/parameter structure, that would be really useful. =20 > For example, it is quite possible to think of an RFID reader that > reads pallet tags and passes them to an application, but that > triggers local alarms (a flashing light, a buzzer?) if certain > anomalous events occur, such as sensing a tag that is not programmed > with an EPC ID or sensing a case-level or item-level tag when there > is no pallet tag present in the field of view. In both of these > cases, the alarm might indicate that further intervention (such as > using a fall-back barcode reader) is needed. SLRRP has an ACL-type filter/operation structure in an access command. = If folks are unclear about access, here are couple of links that explain = the access operations in SLRRP. http://www1.ietf.org/mail-archive/web/rfid/current/msg00125.html http://www1.ietf.org/mail-archive/web/rfid/current/msg00128.html As currently defined, the access command is more focussed on the = followup access operations to be performed on the tags. The op-code is a = byte wide, and each op-spec has its operation-specific parameters. We = have currently defined only a handful of operations (all pertaining to = the air-protocol specific tag memory access commands/operations). To solve the above scenario, we need to define an op-spec that = controls/manipulates GPIO on the reader upon detecting an incorrect tag = pattern. I think thats a valid scenario - a similar request was posed by = Rob of Intermec in an earlier email. If the requirements are well-scoped = (like the above example, but with more details about GPIO addressing = etc), then this group should be able to design it in slrrp. > You could also picture a multi-antenna reader that report inbound > items to middleware (items that are read outside the door and are > later read inside the door), but that triggers an alarm if an item is > moved in the opposite direction. This is entering the domain of inferring higher level events using read = observations from multiple read points. This according to me is a higher = level function. Of course, for the specific deployment case where the = direction has to be inferred from readpoints belonging to the same = reader, the reader itself has the information and hence may have the = logic built in to derive causality of observations. In the general case, = where the readpoints could belong to more than one reader, the = processing logic and communication requirements @ the reader layer to = have distributed inference engines quickly become the dominant factor in = the reader.=20 Having said that, no, SLRRP as currently defined does not support this = specific operation. The general solution requires a causality rule to be = set up at the reader - e.g., if ant1 of reader 1 saw the tag after ant2 = of reader 2, then raise an alarm. I am not convinced that such complicated inference engines need to be = configured via a low-level device interface protocol. SLRRP's = responsibilities include controlling, operating the reader to perform RF = operations (tag inventory, access, RF monitoring), and operate its I/O = peripherals. Data (tag observations) from SLRRP can feed into the = inference logic running on the reader - thats definitely possible.=20 =20 > Also, there is much to be said for having readers that continue to > operate when they do not have network connectivity to the controller, > storing events and reporting them if/when a connection is > established. Ideally, readers should be able to perform their tasks > even if they are rebooted (due to a power outage, for example) and > have not yet established a connection to a controller since > rebooting. They should come up performing their function, and store > data for later retrieval by middleware or applications. >Could SLRRP support this type of autonomous operation? If so, how? Yes. SLRRP does support autonomous operation however whether its the = type you are talking about needs more discussion. SLRRP has primarily 4 = types of commands - configuration, tag inventory, tag access, and the = event reports. Amongst them, the only concerning ones are the last 3. = The tag inventory command has a 'forever' bit which when set instructs = the reader to run the inventory command with the last-configured = singulation/RF/filter parameters forever till it receives a = STOP_INVENTORY command. The tag access commands have been designed to = operate in an autonomous mode - each command creates an access-spec @ = the reader, which gets looked up till a STOP_ACCESS command is sent. If = you read the above links, it'll be clear. Reporting data if/when = connection is established -thats an interesting requirement. The SLRRP = spec as of now defines some triggers to send report back over the = network link to the host/controller. Rob of Intermec had some ideas too. = There are enough bits to support many different types of triggers. It'd = be great if we can work together on ironing out the requirements on this = front. Regarding surviving reboot, power outage etc - thats clearly out of = scope of an interface protocol. Its a reader design issue. And regarding = losing network connection, by definition, the above autonomous operation = should continue even when network connectivity is lost.=20 Good discussion. /Krishna ------_=_NextPart_001_01C58E71.A8357E47 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Rfid] Supported Reader Paradigms=0A= =0A= =0A=
=0A=
> IMO, we should think carefully about = the extent =0A= to which we expect
> RFID readers to be controlled in a top-down = fashion =0A= (receiving
> commands from a "controller", whether those commands = are =0A= immediate or
> trigger-based) vs. the extent that we expect = readers to be =0A= autonomous
> and to operate based on configured policies or =0A= rules.
=0A=
 
=0A=
Supporting a wide range of operational = mode of the reader is certainly a
=0A=
goal of SLRRP. If = anybody has specific =0A= suggestions to augment/modify some of the
=0A=
commands/parameter structure, that would = be really =0A= useful.
=0A=

 

=0A=

> For example, it is quite possible to think of an = RFID =0A= reader that
> reads pallet tags and passes = them to an =0A= application, but that
> triggers local alarms (a flashing light, a =0A= buzzer?) if certain
> anomalous events occur, such as sensing a = tag that =0A= is not programmed
> with an EPC ID or sensing a case-level or = item-level =0A= tag when there
> is no pallet tag present in the field of =0A= view.   In both of these
> cases, the alarm might = indicate that =0A= further intervention (such as
> using a fall-back barcode reader) = is =0A= needed.

=0A=

SLRRP has an ACL-type filter/operation structure in an access =0A= command. If folks are unclear about access, here are couple of = links that =0A= explain the access operations in SLRRP.

=0A=

http://www1.ietf.org/mail-archive/web/rfid/current/msg00125.html

=0A=

http://www1.ietf.org/mail-archive/web/rfid/current/msg00128.html

=0A=

As currently defined, the access command is more focussed = on the =0A= followup access operations to be performed on the tags. The op-code is a = byte =0A= wide, and each op-spec has its operation-specific parameters. We have = currently =0A= defined only a handful of operations (all pertaining to the air-protocol =0A= specific tag memory access commands/operations).

=0A=

To solve the above scenario, we need to define an op-spec that =0A= controls/manipulates GPIO on the reader upon detecting an incorrect tag = pattern. =0A= I think thats a valid scenario - a similar request was posed by Rob of = Intermec =0A= in an earlier email. If the requirements are well-scoped (like the above =0A= example, but with more details about GPIO addressing etc), =0A= then this group should be able to design it in = slrrp.

=0A=

> You could also picture a multi-antenna reader that report =0A= inbound
> items to middleware (items that are read outside the = door and =0A= are
> later read inside the door), but that triggers an alarm if = an item =0A= is
> moved in the opposite direction.

=0A=

This is entering the domain of inferring higher level events using = read =0A= observations from multiple read points. This according to me is a higher = level =0A= function.  Of course, for the specific deployment case where = the =0A= direction has to be inferred from readpoints belonging to the same = reader, the =0A= reader itself has the information and hence may have the logic built in = to =0A= derive causality of observations. In the general case, = where the =0A= readpoints could belong to more than one reader, the = processing logic =0A= and communication requirements @ the reader layer to have = distributed =0A= inference engines quickly become the dominant factor in the =0A= reader. 

=0A=

Having said that, no,  SLRRP as currently defined does not = support =0A= this specific operation. The general solution requires a causality = rule to =0A= be set up at the reader - e.g.,  if ant1 of reader 1 saw the = tag after =0A= ant2 of reader 2, then raise an alarm.

=0A=

I am not convinced that such complicated inference engines need to be =0A= configured via a low-level device interface protocol.  SLRRP's =0A= responsibilities include controlling, operating the reader to perform RF =0A= operations (tag inventory, access, RF monitoring), and operate its = I/O =0A= peripherals. Data (tag observations) from SLRRP can feed into the =0A= inference logic running on the reader - thats definitely possible. =

=0A=

 

=0A=

> Also, there is much to be said for having readers that continue =0A= to
> operate when they do not have network connectivity to the =0A= controller,
> storing events and reporting them if/when a = connection =0A= is
> established.  Ideally, readers should be able to perform = their =0A= tasks
> even if they are rebooted (due to a power outage, for = example) =0A= and
> have not yet established a connection to a controller = since
> =0A= rebooting.  They should come up performing their function, and =0A= store
> data for later retrieval by middleware or =0A= applications.

>Could SLRRP support this type of autonomous =0A= operation?  If so, how?

=0A=

Yes. SLRRP does support autonomous operation however whether its the = type you =0A= are talking about needs more discussion. SLRRP has primarily 4 types of = commands =0A= - configuration, tag inventory, tag access, and the event reports. = Amongst =0A= them, the only concerning ones are the last 3. The tag inventory command = has a =0A= 'forever' bit which when set instructs the reader to run the = inventory =0A= command with the last-configured singulation/RF/filter parameters = forever till =0A= it receives a STOP_INVENTORY command. The tag access commands have been = designed =0A= to operate in an autonomous mode - each command creates an access-spec @ = the =0A= reader, which gets looked up till a STOP_ACCESS command is sent.  = If you =0A= read the above links, it'll be clear. Reporting data if/when connection = is =0A= established -thats an interesting requirement. The SLRRP spec as of = now =0A= defines some triggers to send report back over the network link to the =0A= host/controller. Rob of Intermec had some ideas too. There are = enough bits =0A= to support many different types of triggers. It'd be great if we can = work =0A= together on ironing out the requirements on this front.

=0A=

Regarding surviving reboot, power outage etc - thats clearly out of = scope of =0A= an interface protocol. Its a reader design issue. And regarding losing = network =0A= connection, by definition, the above autonomous operation should = continue even =0A= when network connectivity is lost.

=0A=

Good discussion.

=0A=

/Krishna

=0A= =0A= =0A= ------_=_NextPart_001_01C58E71.A8357E47-- --===============1511056988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1511056988==-- From rfid-bounces@lists.ietf.org Fri Jul 22 04:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvsks-000547-BX; Fri, 22 Jul 2005 04:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvskp-00053z-NJ for rfid@megatron.ietf.org; Fri, 22 Jul 2005 04:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22380 for ; Fri, 22 Jul 2005 04:19:33 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvtEx-0001VE-Cg for rfid@ietf.org; Fri, 22 Jul 2005 04:50:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 3B60B26C135; Fri, 22 Jul 2005 10:19:08 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 1B66B26C134; Fri, 22 Jul 2005 10:19:07 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j6M8J6uT774732; Fri, 22 Jul 2005 10:19:06 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id AE3E116A9D9; Fri, 22 Jul 2005 10:19:06 +0200 (CEST) Date: Fri, 22 Jul 2005 10:19:06 +0200 From: Stephane Bortzmeyer To: David Husak Message-ID: <20050722081906.GA16237@nic.fr> References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rfid@ietf.org Subject: [Rfid] Re: XML vs. Text vs. Binary X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org On Thu, Jul 21, 2005 at 07:56:22PM -0400, David Husak wrote a message of 213 lines which said: > In a compact, fixed binary encoding, it's easy for an implementation > to access protocol fields directly via indexed load and store, > i.e. an implementation need only access the bytes it needs, and it > knows where those bytes are. #define WARNING "newbie" I've read quite often this statement in IETF discussions. I am not an implementer but I wonder if this idea of blindly retrieving bits coming from the newtork is really what the implementers do. Because it seems there is a security issue here: since the bits come from a possibly untrusted source (either because it is malicious or because it is buggy), you surely validate them in some way, first, and therefore you have to parse the incoming data, no? _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 06:57:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvDF-0008Nz-UB; Fri, 22 Jul 2005 06:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvDE-0008Nu-Aj for rfid@megatron.ietf.org; Fri, 22 Jul 2005 06:57:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01538 for ; Fri, 22 Jul 2005 06:57:00 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvvhR-0007ly-W1 for rfid@ietf.org; Fri, 22 Jul 2005 07:28:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] Re: XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 06:56:14 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] Re: XML vs. Text vs. Binary Thread-Index: AcWOliwV7/wMQSaOQTSamxMVa8/4ZwAFKFDg From: "Scott Barvick" To: "Stephane Bortzmeyer" , "David Husak" X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1756045314==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1756045314== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58EAB.FAA86F23" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58EAB.FAA86F23 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephane, =20 >From the security perspective, the protocol processing is layered on top = of standard security mechanisms as discussed in Section 4.2 of the = draft. Therefore, the implementation can safely access fields in = payload as efficiently as possible. =20 Scott ________________________________ From: rfid-bounces@lists.ietf.org on behalf of Stephane Bortzmeyer Sent: Fri 7/22/2005 4:19 AM To: David Husak Cc: rfid@ietf.org Subject: [Rfid] Re: XML vs. Text vs. Binary On Thu, Jul 21, 2005 at 07:56:22PM -0400, David Husak wrote a message of 213 lines which said: > In a compact, fixed binary encoding, it's easy for an implementation > to access protocol fields directly via indexed load and store, > i.e. an implementation need only access the bytes it needs, and it > knows where those bytes are. #define WARNING "newbie" I've read quite often this statement in IETF discussions. I am not an implementer but I wonder if this idea of blindly retrieving bits coming from the newtork is really what the implementers do. Because it seems there is a security issue here: since the bits come from a possibly untrusted source (either because it is malicious or because it is buggy), you surely validate them in some way, first, and therefore you have to parse the incoming data, no? _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------_=_NextPart_001_01C58EAB.FAA86F23 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Rfid] Re: XML vs. Text vs. Binary=0A= =0A= =0A=
=0A=
Stephane,
=0A=
 
=0A=
From the security = perspective, the protocol =0A= processing is layered on top of standard security mechanisms as = discussed in =0A= Section 4.2 of the draft.  Therefore, the implementation can safely = access =0A= fields in payload as efficiently as possible.
=0A=
 
=0A=
Scott
=0A=

=0A=
=0A= From: rfid-bounces@lists.ietf.org on = behalf of =0A= Stephane Bortzmeyer
Sent: Fri 7/22/2005 4:19 AM
To: = David =0A= Husak
Cc: rfid@ietf.org
Subject: [Rfid] Re: XML vs. = Text vs. =0A= Binary

=0A=
=0A=

On Thu, Jul 21, 2005 at 07:56:22PM = -0400,
 David Husak =0A= <dhusak@revasystems.com> wrote
 a message of 213 lines = which =0A= said:

> In a compact, fixed binary encoding, it's easy for an =0A= implementation
> to access protocol fields directly via indexed = load and =0A= store,
> i.e. an implementation need only access the bytes it = needs, and =0A= it
> knows where those bytes are.

#define WARNING =0A= "newbie"

I've read quite often this statement in IETF = discussions. I am =0A= not an
implementer but I wonder if this idea of blindly retrieving =0A= bits
coming from the newtork is really what the implementers do. = Because =0A= it
seems there is a security issue here: since the bits come from =0A= a
possibly untrusted source (either because it is malicious or = because
it =0A= is buggy), you surely validate them in some way, first, and
therefore = you =0A= have to parse the incoming data, =0A= no?

_______________________________________________
Rfid = mailing =0A= list
Rfid@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/rfid

=0A= =0A= =0A= ------_=_NextPart_001_01C58EAB.FAA86F23-- --===============1756045314== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1756045314==-- From rfid-bounces@lists.ietf.org Fri Jul 22 07:34:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvnA-000735-K5; Fri, 22 Jul 2005 07:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvvn9-00072x-F9 for rfid@megatron.ietf.org; Fri, 22 Jul 2005 07:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03763 for ; Fri, 22 Jul 2005 07:34:10 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwHM-0000u0-MN for rfid@ietf.org; Fri, 22 Jul 2005 08:05:26 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A1B3A395A8; Fri, 22 Jul 2005 13:33:52 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03524-05; Fri, 22 Jul 2005 13:33:51 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 7E5C7390EE; Fri, 22 Jul 2005 13:33:51 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 1F1DF392779; Fri, 22 Jul 2005 13:33:49 +0200 (CEST) Date: Fri, 22 Jul 2005 13:33:49 +0200 From: Juergen Schoenwaelder To: Scott Barvick Subject: Re: [Rfid] Re: XML vs. Text vs. Binary Message-ID: <20050722113349.GA21188@boskop.local> References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote: > Stephane, > > From the security perspective, the protocol processing is layered on > top of standard security mechanisms as discussed in Section 4.2 of > the draft. Therefore, the implementation can safely access fields > in payload as efficiently as possible. I will leave it to implementors to decide whether they want to be robust against broken implementations or not. However, I like to point out two things: a) As long as security processing is done in software, this will weight more than any encoding/decoding required, whether that is a binary format or not does not matter. b) Our SNMP experience is that encoding/decoding is not at all an issue when it comes to the amount of CPU cycles burned. Most of the time is spend accessing the instrumentation and in the security processing (if enabled). So if you want to optimize CPU usage, make sure you look at the whole system and spend the efforts where you can maximize the benefit. Human readability is a major enabling factor. In theory, all you need is a decent library to handle binary encodings well but in the real world it seems to help if people can do things without relying on such a library. Human readable encodings (and I include XML here) simply enable more people to get into the "game" and this is ultimately driving the success of a technology. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 07:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvvW-00039t-1u; Fri, 22 Jul 2005 07:42:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvvU-00039o-Lm for rfid@megatron.ietf.org; Fri, 22 Jul 2005 07:42:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04484 for ; Fri, 22 Jul 2005 07:42:47 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwPi-0001In-8b for rfid@ietf.org; Fri, 22 Jul 2005 08:14:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id C6F9926C084; Fri, 22 Jul 2005 13:42:40 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 9B34826C077; Fri, 22 Jul 2005 13:42:39 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j6MBgduT824519; Fri, 22 Jul 2005 13:42:39 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 4541F16A9D9; Fri, 22 Jul 2005 13:42:39 +0200 (CEST) Date: Fri, 22 Jul 2005 13:42:39 +0200 From: Stephane Bortzmeyer To: Scott Barvick Message-ID: <20050722114239.GA23843@nic.fr> References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rfid@ietf.org Subject: [Rfid] Re: XML vs. Text vs. Binary X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote a message of 121 lines which said: > the protocol processing is layered on top of standard security > mechanisms as discussed in Section 4.2 of the draft. Section 4.2 is nice but it just says that TLS MUST be present, not that it MUST be used, no? > Therefore, the implementation can safely access fields in payload as > efficiently as possible. It seems to me quite contradictory to say (David Husak's message) "We will use fixed-length encoding because it is faster" and "security is not an issue, since we use TLS". Surely, TLS processing is much more costly than XML processing and therefore the cost of XML is negligible? _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 07:50:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvw2X-00070b-I9; Fri, 22 Jul 2005 07:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvw2V-000705-Sb for rfid@megatron.ietf.org; Fri, 22 Jul 2005 07:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05170 for ; Fri, 22 Jul 2005 07:50:02 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwWj-0001eR-DK for rfid@ietf.org; Fri, 22 Jul 2005 08:21:18 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 07:49:56 -0400 From: Scott Barvick To: Stephane Bortzmeyer In-Reply-To: <20050722114239.GA23843@nic.fr> References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> <20050722114239.GA23843@nic.fr> Content-Type: text/plain Message-Id: <1122032992.26431.2.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 22 Jul 2005 07:49:52 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2005 11:49:56.0258 (UTC) FILETIME=[7AED2820:01C58EB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org Subject: [Rfid] Re: XML vs. Text vs. Binary X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org You are correct to note that TLS is not required to be used. However, if you are concerned about security, which was the basis for your first question, then you can use it. There are environments where the security concerns that you raise are not an issue. For those and the base case, I argue for efficient, mimimal requirements on the implementations. Scott On Fri, 2005-07-22 at 07:42, Stephane Bortzmeyer wrote: > On Fri, Jul 22, 2005 at 06:56:14AM -0400, > Scott Barvick wrote > a message of 121 lines which said: > > > the protocol processing is layered on top of standard security > > mechanisms as discussed in Section 4.2 of the draft. > > Section 4.2 is nice but it just says that TLS MUST be present, not > that it MUST be used, no? > > > Therefore, the implementation can safely access fields in payload as > > efficiently as possible. > > It seems to me quite contradictory to say (David Husak's message) "We > will use fixed-length encoding because it is faster" and "security is > not an issue, since we use TLS". Surely, TLS processing is much more > costly than XML processing and therefore the cost of XML is > negligible? > > _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 08:08:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvwKK-000875-27; Fri, 22 Jul 2005 08:08:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvwKI-00085h-Oc for rfid@megatron.ietf.org; Fri, 22 Jul 2005 08:08:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06840 for ; Fri, 22 Jul 2005 08:08:24 -0400 (EDT) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvwoX-0002Qb-7M for rfid@ietf.org; Fri, 22 Jul 2005 08:39:41 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 08:08:04 -0400 Subject: Re: [Rfid] Re: XML vs. Text vs. Binary From: Scott Barvick To: j.schoenwaelder@iu-bremen.de In-Reply-To: <20050722113349.GA21188@boskop.local> References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> <20050722113349.GA21188@boskop.local> Content-Type: text/plain Message-Id: <1122034083.26431.32.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 22 Jul 2005 08:08:03 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2005 12:08:04.0104 (UTC) FILETIME=[03554880:01C58EB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org It is probably important to point out on this thread as well that security and human readability are mutually exclusive, and security needs will trump human readability (including binary decodes through open source, free tools such as Ethereal) any day. So designing for human readability in what is inherently machine-to-machine operation does not seem like a requirement, especially if RFID deployments grow the way we all believe they will. Scott On Fri, 2005-07-22 at 07:33, Juergen Schoenwaelder wrote: > On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote: > > Stephane, > > > > From the security perspective, the protocol processing is layered on > > top of standard security mechanisms as discussed in Section 4.2 of > > the draft. Therefore, the implementation can safely access fields > > in payload as efficiently as possible. > > I will leave it to implementors to decide whether they want to be > robust against broken implementations or not. However, I like to point > out two things: > > a) As long as security processing is done in software, this will weight > more than any encoding/decoding required, whether that is a binary > format or not does not matter. > > b) Our SNMP experience is that encoding/decoding is not at all an > issue when it comes to the amount of CPU cycles burned. Most of > the time is spend accessing the instrumentation and in the security > processing (if enabled). So if you want to optimize CPU usage, > make sure you look at the whole system and spend the efforts > where you can maximize the benefit. > > Human readability is a major enabling factor. In theory, all you need > is a decent library to handle binary encodings well but in the real > world it seems to help if people can do things without relying on > such a library. Human readable encodings (and I include XML here) > simply enable more people to get into the "game" and this is > ultimately driving the success of a technology. > > /js _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 09:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxsQ-00016Q-LK; Fri, 22 Jul 2005 09:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxsO-00015N-Oa for rfid@megatron.ietf.org; Fri, 22 Jul 2005 09:47:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15684 for ; Fri, 22 Jul 2005 09:47:42 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvyMd-0006Ak-4n for rfid@ietf.org; Fri, 22 Jul 2005 10:19:00 -0400 Received: from ([10.100.101.63]) by relay3.manh.com with ESMTP id 4029073.7179869; Fri, 22 Jul 2005 09:46:35 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Fri, 22 Jul 2005 09:46:34 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 09:46:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] Re: XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 09:46:34 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBF6@ma-atl57.us.manh.com> Thread-Topic: [Rfid] Re: XML vs. Text vs. Binary Thread-Index: AcWOswuJe8YhvV9jQHqMfS2AXZxPtAAEE0ZA From: "Howard Kapustein" To: "Stephane Bortzmeyer" , "Scott Barvick" X-OriginalArrivalTime: 22 Jul 2005 13:46:34.0507 (UTC) FILETIME=[C63535B0:01C58EC3] X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >therefore the cost of XML is negligible? Cost has several dimensions, not just cpu. For instance, memory utilization can also be a significant factor. I have no idea how XML vs. TLS stack up on that front. But we should be clear when we're discussing such things we clearly understand what we're referring to, and not lumping disparate things together under one jambalaya umbrella. - Howard -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Stephane Bortzmeyer Sent: Friday, July 22, 2005 7:43 AM To: Scott Barvick Cc: rfid@ietf.org Subject: [Rfid] Re: XML vs. Text vs. Binary On Fri, Jul 22, 2005 at 06:56:14AM -0400, Scott Barvick wrote=20 a message of 121 lines which said: > the protocol processing is layered on top of standard security > mechanisms as discussed in Section 4.2 of the draft. Section 4.2 is nice but it just says that TLS MUST be present, not that it MUST be used, no? > Therefore, the implementation can safely access fields in payload as > efficiently as possible. It seems to me quite contradictory to say (David Husak's message) "We will use fixed-length encoding because it is faster" and "security is not an issue, since we use TLS". Surely, TLS processing is much more costly than XML processing and therefore the cost of XML is negligible? _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:03:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvy7v-0007ri-VI; Fri, 22 Jul 2005 10:03:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvy7v-0007mw-34 for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:03:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16935 for ; Fri, 22 Jul 2005 10:03:44 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvyc9-0006rQ-PQ for rfid@ietf.org; Fri, 22 Jul 2005 10:35:03 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 448523; Fri, 22 Jul 2005 09:57:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050722114239.GA23843@nic.fr> References: <0E03681B885F3B4296B999E34435A16E37344E@ms08.mse3.exchange.ms> <20050722114239.GA23843@nic.fr> Date: Fri, 22 Jul 2005 10:00:53 -0400 To: Stephane Bortzmeyer , Scott Barvick From: Margaret Wasserman Subject: Contradictions (Was: [Rfid] Re: XML vs. Text vs. Binary) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org The other inherent contradiction that I see in these discussions is: (1) We need to use a binary encoding because the latency of decoding XML would interfere with SLRRP's real-time requirements, AND (2) Our secure transport will the TLS over TCP/IP. What is wrong with this picture? This is why I keep getting back to the question of what the real-time requirements actually are. It seems very unlikely to me that TLS over TCP/IP would meet the goals of a "real-time control protocol", but that parsing XML on top of that would push us over the edge... I can't make a coherent argument on that front, though, because I see absolutely no real-time requirements. What are the real-time requirements for a controller that says, effectively "Here are your inventory settings, run this until I say stop. I'll be back later to pick up the data."? Margaret At 1:42 PM +0200 7/22/05, Stephane Bortzmeyer wrote: >On Fri, Jul 22, 2005 at 06:56:14AM -0400, > Scott Barvick wrote > a message of 121 lines which said: > >> the protocol processing is layered on top of standard security >> mechanisms as discussed in Section 4.2 of the draft. > >Section 4.2 is nice but it just says that TLS MUST be present, not >that it MUST be used, no? > >> Therefore, the implementation can safely access fields in payload as >> efficiently as possible. > >It seems to me quite contradictory to say (David Husak's message) "We >will use fixed-length encoding because it is faster" and "security is >not an issue, since we use TLS". Surely, TLS processing is much more >costly than XML processing and therefore the cost of XML is >negligible? > > > >_______________________________________________ >Rfid mailing list >Rfid@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:16:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyHg-0003KU-GX; Fri, 22 Jul 2005 10:13:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyHe-0003KI-IY for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:13:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18207 for ; Fri, 22 Jul 2005 10:13:48 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvylt-0007Ex-Cb for rfid@ietf.org; Fri, 22 Jul 2005 10:45:06 -0400 Received: from ([10.100.101.63]) by relay3.manh.com with ESMTP id 4029073.7183986; Fri, 22 Jul 2005 10:12:57 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Fri, 22 Jul 2005 10:12:56 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:12:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 10:12:54 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBF8@ma-atl57.us.manh.com> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWOaGeU2DrTJeJbSLGoBcLKhdAVBgAXiK7Q From: "Howard Kapustein" To: "Marshall Rose" , "Margaret Wasserman" X-OriginalArrivalTime: 22 Jul 2005 14:12:55.0283 (UTC) FILETIME=[746C7C30:01C58EC7] X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >it's certainly better than binary if you're going to type-in commands =20 >via telnet or ssh. the moment you have to start matching elements, =20 >and are typing more than a few of them, you need to have a tool do =20 >the typing. a) Who said "text" means "xml" ? XML is an option, but in a 3-way fight 'binary' goes down early in the fight, and the real question is if XML or non-xml-text format should be the basis for the syntax. Syntax. That's all XML buys you 'for free'. [Well, that plus a lotta tools, but also some drawbacks] The magic XML wand doesn't inherently solve Vocabulary nor Semantics. Just syntax. Ditto for Text. And points made by both Marshall + Margaret, IMO, also emphasize the need for a good non-XML textual format. Check out HTTP. Now SOAP and XML-RPC. Now go sniff a wire for DCOM, or IIOP, or NDR. Hey, go play with some ASN.1. Text vs. XML vs. Binary. XML's nice in some ways, but less desirable than text for human reasons. [And tools; there are many XML tools, but even more 'structured text handling' options] And both are far superior to Binary. IMNSHO, of course :-) - Howard -----Original Message----- From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On Behalf Of Marshall Rose Sent: Thursday, July 21, 2005 10:48 PM To: Margaret Wasserman Cc: rfid@ietf.org Subject: Re: [Rfid] XML vs. Text vs. Binary > So, I will restate my opinion that we should not lightly develop an =20 > RFID reader management protocol that can only be access from a =20 > specialized client. i guess we'd need to agree on the meaning of specialized before =20 agreeing on this point. > To your point about enumerated types, etc.... There is no reason =20 > why a text interface couldn't allow well-defined strings to be used =20 > for those enumerations (EPC0, EPC1, EPCG2, etc...), rather than =20 > requiring the client (whether it is a piece of middleware, a Perl =20 > script or a human typing at an SSH prompt) to send numerical values. the problem, i think, is that the XML compromise, like most =20 compromises, doesn't really solve anything; further, like most =20 compromises, it works worse than most purist approaches. it's certainly better than binary if you're going to type-in commands =20 via telnet or ssh. the moment you have to start matching elements, =20 and are typing more than a few of them, you need to have a tool do =20 the typing. as soon as you have tool do it, you've lost the text advantage =20 because it's just as easy for a tool, perl-based or not, to spit out =20 binary as xml. my experience, which admittedly is dated, is that text works for =20 debugging simple protocols like smtp. as soon as you introduce =20 nesting, you lose the type-in advantage. /mtr ps: people who complain about the binary nature of snmp are actually =20 complaining, whether they know it or not, about ASN.1/BER, which =20 define how to describe and encode SNMP packets. i really should have =20 listened more to chuck davin 20 years ago... _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:29:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyWL-0001QQ-IZ; Fri, 22 Jul 2005 10:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyWJ-0001QG-BB for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:28:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20121 for ; Fri, 22 Jul 2005 10:28:56 -0400 (EDT) Received: from charles.revasystems.com ([65.209.89.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvz0Y-0007uc-G9 for rfid@ietf.org; Fri, 22 Jul 2005 11:00:15 -0400 Received: from [192.168.1.50] (avon [192.168.1.50]) by charles.revasystems.com (Postfix) with ESMTP id 2DEAE3BE90; Fri, 22 Jul 2005 10:28:45 -0400 (EDT) Subject: Re: FW: [Rfid] SLRRP Vendor Extensions From: Peter Spreadborough To: Suresh Bhaskaran In-Reply-To: <200507211720.j6LHKCx4004859@mail.intelleflex.com> References: <200507211720.j6LHKCx4004859@mail.intelleflex.com> Content-Type: text/plain Message-Id: <1122042525.10159.77.camel@avon> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 22 Jul 2005 10:28:45 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Suresh, Your suggestion sounds like an interesting one, my understanding of it is that the message format would now be: 0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|x|x|x|V| Ver | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |x x x x x x x x x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Vendor ID : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Message Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Setting the V bit will indicate the presence of the VendorID field in the message header. If the V bit is not set then the VendorID will not be present. On receipt of a message with the V bit set an implementation may decide to accept or reject that message. NOTE: The error codes should be expanded to include a reason code to indicate the rejection of messages or parameters with vendor extensions. How would a standard SLRRP message, say GET_READER_INFO, be interpreted if the V bit where set? would the V bit indicate that the GET_READER_INFO message header where non-standard or that the parameters are non-standard? Would parameters header also include a V bit as per my original suggestion? Pete On Thu, 2005-07-21 at 13:19, Suresh Bhaskaran wrote: > The way this is defined, the vendor ID is a required field for *all* message > headers now? Is this the intention? > > Might there be a way to leave the messages the same, and only include the > vendor ID in the message header if it is a vendor extension? > > The V-bit as stated, is only for the parameter. If we had the equivalent of > a V-bit for the message, then we don't have to include the Vendor ID in all > message headers? > > Suresh > > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Peter Spreadborough > Sent: Wednesday, July 20, 2005 3:44 PM > To: rfid@ietf.org > Subject: [Rfid] SLRRP Vendor Extensions > > > To facilitate the support of vendor specific extensions, prior to formal > inclusion into the protocol, the following solution is proposed: > > 1. The SLRRP message header will be extended to include a thirty two bit > vendor ID field: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |x|x|x|x|x| Ver | Message Type | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Seq Num |x x x x x x x x x x x x x x x x| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : Message Value : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 2. For SLRRP parameters a bit from the "user" bits will be assigned as > the Vendor or V bit. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | A |V|User | Parameter Type | Parameter Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : : > : Parameter Value : > : : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 3. A block of unused message types will be reserved for vendor > extensions. > 4. A block of parameter types will be reserved for vendor extensions. > > SLRRP implementations may choose to ignore: > - Any message types that fall in to the vendor extension range. > - Any parameter types that fall into the vendor extension range. > - Any parameters that have the V bit set. > > If the V bit is set in a parameter header then the vendor ID used in the > encapsulating message will apply. The parameter may then be accepted or > ignored based on the vendor ID. This applies to both defined message > types and extended message types. > > > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:37:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyeU-0005Qr-DI; Fri, 22 Jul 2005 10:37:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyeT-0005Qm-8a for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20701 for ; Fri, 22 Jul 2005 10:37:22 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvz8h-0008C4-OB for rfid@ietf.org; Fri, 22 Jul 2005 11:08:41 -0400 Received: from ([10.100.101.63]) by relay3.manh.com with ESMTP id 4029073.7185807; Fri, 22 Jul 2005 10:36:08 -0400 Received: from ma-atl97.us.manh.com ([10.100.101.97]) by ma-atl63 with trend_isnt_name_B; Fri, 22 Jul 2005 10:06:05 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl97.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:06:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] Re: XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 10:06:05 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEBF7@ma-atl57.us.manh.com> Thread-Topic: [Rfid] Re: XML vs. Text vs. Binary Thread-Index: AcWOtrD9UpWdtpYBRTOscmq8grAXcgADSFiw From: "Howard Kapustein" To: X-OriginalArrivalTime: 22 Jul 2005 14:06:05.0564 (UTC) FILETIME=[803653C0:01C58EC6] X-esp: ESP<4>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<0> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >So designing for human readability in what is inherently machine-to-machine >operation does not seem like a requirement, I'd agree, except there's one flaw in your statement: Humans *are* involved. Unless you've found a way for machines to build the machines to talk to machines, but I thought SkyNet wasn't operational yet. I've worked with a variety of protocols and formats, and to be honest if I have to deal with one more friggin' binary protocol I'm going to have the urge (yet again) to kill something. The efficiency tradeoff is largely a red herring. *Pragmatically* speaking, it's a wash. There are some minor perturbations each way, but they're not significant. Not in this space. I've seen various encodings. I've done the math. I've written code, both high and level level, to build and parse such data streams. I've even shipped products. ***It's a wash.*** A *well-designed* text format is equivalent to a *well-designed* binary format, in terms of size, memory utilization, parse efficiency and so forth, for these needs. But...when it comes to *using* the format, TEXT IS ALWAYS SUPERIOR TO BINARY. Unless someone knows a way to take the 'human' factor out of it. Text formats are far more amenable to lower effort to use, to troubleshoot and to do so correctly. They lower the barrier to entry. The encourage more exploration more easily. Given the technical delta is effectively nil, and the *human* factor is significantly tilted in favor of a textual/non-binary format, I fail to see how a 'binary' format is compelling over 'text'. On the efficiency side, I would love to see someone challenge my assertion -- WITH NUMBERS. No anecdotes. No opinions. Cold hard clear factual values. - Howard P.S. When I say 'text' I mean non-binary, in the traditional senses of the words. XML is textual, but often fails the bandwidth/size issue vs. other (esp. more specialized) text formats, designed for more efficient size + utilization. XML is great for data not because it's inherently great, but because everyone (esp. every vendor) agreed "it's good enough". The *everyone* part is why XML is successful. YAML, JSON and other formats are superior in some technical ways, but given the breadth acceptance ("even if we don't love it, we don't hate it") it's often a good solution. In this case? That's up for debate. But ignore XML; it's a subset of 'text'. In the 'binary' vs. 'text' Steel Cage Deathmatch, both will be bloodied, both will be weary, and **the audience** will come on stage and crown 'text' the champion. _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:43:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvykc-0007Bj-Ed; Fri, 22 Jul 2005 10:43:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvyka-0007Be-6X for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:43:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21257 for ; Fri, 22 Jul 2005 10:43:41 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzEq-0008Sc-20 for rfid@ietf.org; Fri, 22 Jul 2005 11:15:00 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 448589; Fri, 22 Jul 2005 10:37:35 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Date: Fri, 22 Jul 2005 10:42:04 -0400 To: Marshall Rose From: Margaret Wasserman Subject: Re: [Rfid] XML vs. Text vs. Binary Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi Marshall, At 8:17 AM +0530 7/22/05, Marshall Rose wrote: >i guess we'd need to agree on the meaning of specialized before >agreeing on this point. Yes, absolutely. The distinction I would make is that "specialized" == written specifically for this protocol. A TCP/IP stack, an SSL client and a canonical XML parser aren't specialized, because those are widely deployed technologies that are used for things other than this specific reader control protocol. They are already available for most OS's and HW platforms, there are embedded and non-embedded versions of them available, etc. A parser for a SLRRP-specific text or binary protocol and/or a library that understands how to break higher level functions into specific SLRRP commands would be "specialized", by my definition. As an example... If SNMP's subset of ASN.1 and/or it's BER encoding had been more widely used, then there might have been widely deployed, non-specialized tools that could encode/decode SNMP PDUs (there aren't, unfortunately). However, SNMP's PDU structure is specific to SNMP and requires a specialized tool to parse incoming messages and/or format outgoing messages. IMO, the more we can leverage non-specialized, widely deployed technology (such as TCP/IP, SSH or TLS, XML, etc.) on both the client and reader sides, the better. People will be able to build clients and/or readers that are stable and robust in much less time if they can use tools/libraries for this purpose that have already been written and debugged. It lowers the barrier for entry and (most importantly, IMO) makes it possible for anyone with basic Perl, Python or Ruby programming skills to interact with a reader using our protocol and widely-available tools and libraries. My preference for using canonical XML is based on three things: (1) I think that we should focus only on network-connected RFID readers. There are very limited, low-cost DSP-only readers available (including one from ThingMagic), but these are embedded modules that are accessed over serial lines from a host CPU, and they are included in devices like label printers and box folders. If it is necessary to control the RFID reader portion of these devices over the network, that will have to be done through the host CPU, anyway. It isn't practical to put TLS/TCP/IP on those embedded devices, so the fact that it isn't practical to run an XML parser on those devices is moot, IMO. (2) There are embedded (or embeddable) XML parsers available (like expat) that can parse canonical XML using a SAX parser. These parsers are neither CPU-intensive nor memory-intensive compared to a TCP/IP stack, DHCP, TFTP (or FTP or both), NTP, a DNS resolver, HTTP, TLS, OpenSSL (or your favorite encryption library), some web pages, SSH (or Telnet?), some command-line management/configuration tools, and all of the code necessary to implement EPC Global's Gen2 specification including the anti-collision and dense reader mode features. I fully expect that all of this (and maybe more -- SNMP, MIB-2 and RFID MIBs?) will be available on every network-accessible Gen2 RFID reader. (3) I do not believe that we should design RFID networks so that there is a real-time requirement for communication of control data between a controller and many readers. But, even if we did, I cannot picture a world in which the XML parsing is a big latency factor in a system that involves network transmission of control information over TLS/TCP/IP on the same network that is used for the data communication. I understand, though, that some people do not find XML acceptable because of its bandwidth requirements... If that is a real concern (and I'd like to see some explanation of why it would be a real concern), then I'd like to see if we could address that concern through _how_ we encode the information in XML, or through a specialized text encoding. Either approach would still maintain some of the benefits of XML -- like the ability to interact with the reader using text-processing tools without using a specialized (as defined above) parser on the client side. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 10:49:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvyq8-0000sp-UN; Fri, 22 Jul 2005 10:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvyq7-0000r8-77 for rfid@megatron.ietf.org; Fri, 22 Jul 2005 10:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21553 for ; Fri, 22 Jul 2005 10:49:24 -0400 (EDT) Received: from nat2.manh.com ([65.166.51.6] helo=manh.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzKL-0000Bi-U6 for rfid@ietf.org; Fri, 22 Jul 2005 11:20:43 -0400 Received: from ([10.100.101.63]) by relay3.manh.com with ESMTP id 4029073.7187114; Fri, 22 Jul 2005 10:48:18 -0400 Received: from ma-atl96.us.manh.com ([10.100.101.96]) by ma-atl63 with trend_isnt_name_B; Fri, 22 Jul 2005 10:48:17 -0400 Received: from ma-atl57.us.manh.com ([10.100.101.57]) by ma-atl96.us.manh.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 10:48:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] XML vs. Text vs. Binary Date: Fri, 22 Jul 2005 10:48:16 -0400 Message-ID: <02254DCB1D0B2340B8D1D54E770CAE76DAEC06@ma-atl57.us.manh.com> Thread-Topic: [Rfid] XML vs. Text vs. Binary Thread-Index: AcWOy/men23MQjeQQS+Yrpha2kNWXwAAFYlg From: "Howard Kapustein" To: "Margaret Wasserman" , "Marshall Rose" X-OriginalArrivalTime: 22 Jul 2005 14:48:17.0027 (UTC) FILETIME=[6514ED30:01C58ECC] X-esp: ESP<6>=RBL:<0> RDNS:<0> SHA:<4> UHA:<0> SLS:<0> BAYES:<2> SPF:<0> CAN-SPAM Compliance Dictionary (TRU7a):<0> NigeriaScam Dictionary (TRU7a):<0> Obscenities Dictionary (TRU7a):<0> Spam Dictionary (TRU7a):<0> Porn Dictionary (TRU7a):<0> Embed HTML Dictionary (TRU7a):<0> URL Dictionary (TRU7a):<0> HTML Dictionary (TRU7a):<0> X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: quoted-printable Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org >basic Perl, Python or Ruby Which of these is not like the others? :-> _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 11:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvzto-0006Kd-28; Fri, 22 Jul 2005 11:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvztm-0006KY-E0 for rfid@megatron.ietf.org; Fri, 22 Jul 2005 11:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27827 for ; Fri, 22 Jul 2005 11:57:15 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0O3-0002xG-7O for rfid@ietf.org; Fri, 22 Jul 2005 12:28:35 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 448682 for rfid@ietf.org; Fri, 22 Jul 2005 11:51:10 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 22 Jul 2005 11:56:31 -0400 To: rfid@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Subject: [Rfid] Management vs. Control vs. Data X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Another thought on our RFID reader control protocol (whatever we decide to name it)... It seems to me that some of our discussions are mixing together the control plane (or control functions) and the data plane (or data functions). We also seem to be combining the concepts of single reader control and multi-reader control (which includes concepts such as synchronization). On some level, the management plane also seems to be conflated. I think that we should be very clear about defining/understanding the functional blocks to in our RFID network architecture, and I think that we need to understand the relationships between those blocks and the requirements for each of them _before_ we decide that SLRRP is the correct starting place for an RFID reader control protocol. The SLRRP protocol seems to make some basic assumptions in this area that I question. It seems to assume four things: (1) That there will be a one-to-many mapping between RFID controllers and RFID readers. In other words, that only one controller (whether it is running on the reader, a controller device, a piece of networking equipment or a server) will be controlling a given reader at any point in time. Given the nature of RFID readers, this _might_ be reasonable, although I would welcome alternatives. (This is a control plane function.) (2) That single reader control functions and multi-reader control functions (such as synchronization) will both be controlled by the same controller functional unit. (Another control plane function.) (3) That the same functional unit that is controlling the reader will be the only first-line consumer for all of the readers' tag data and other events. (This is a data plane function.) AND (3) That the same functional unit will serve as the arbiter for all management/monitoring requests (this is a Management plane function.) Actually, I am not sure that this is really intended in SLRRP, but it is implied by this text in the proposed charter: We envision a typical RFID deployment comprising of a network of RFID readers controlled by one or more reader network controller elements (which may be software in a server, RFID reader, control blade of a router/switch, or a standalone device). These controller elements in turn are connected to hosts/servers running client applications that ultimately consume the acquired tag data and management applications that monitor the operation of the reader network. Do these three restrictions/conflations actually make sense? I understand why (perhaps?) there should be a single controller that is taking requests from multiple applications and determining what RFID functions a specific reader should perform in order to carry out those requests. This code could run on a smart reader itself, or on external node that controls one or more less-smart readers. However, I see no reason why this one controller should be a choke point for the data plane. The controller could configure the reader to know about one or more consumers and set filters that indicate what data should be sent to those consumers. Then, the reader could transmit the data to the consumers directly. This removes a third-party dependency on the controller in order for a reader that is operating autonomously (perhaps as configured by the controller) to send its data to a set of consumers. I also understand that there might be a multi-reader coordination function that would generally run external to any of the readers. Although this is also a control-plane function, it might be better to break the single-reader control and multi-reader control into two separate functional boxes in our architecture, so that they can run in independent locations. What do others think? And, I certainly don't understand why an RFID controller should be involved in the management/monitoring of a reader -- I should be able to use a commercial management station (like Tivoli or HP Open View) to monitor the health of my readers and the state of their RFID functions via SNMP or other protocols without involving any third party. Right? For much-less-smart readers that are not capable of supporting SNMP, a proxy could run somewhere, I suppose... But this doesn't have to be the same functional unit as the controller. Are there specific reasons why the SLRRP architecture has a single controller handle the control, data and management functions? Breaking these things into separate functional units in our architecture would not stop someone from running all of them on a single CPU, but it would allow us the flexibility to place different types of functionality at different places in the RFID network. Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 12:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw08K-0002ez-SP; Fri, 22 Jul 2005 12:12:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw08J-0002ZU-5V for rfid@megatron.ietf.org; Fri, 22 Jul 2005 12:12:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29121 for ; Fri, 22 Jul 2005 12:12:16 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0cZ-0003dq-2f for rfid@ietf.org; Fri, 22 Jul 2005 12:43:36 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 448740; Fri, 22 Jul 2005 12:06:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1122042525.10159.77.camel@avon> References: <200507211720.j6LHKCx4004859@mail.intelleflex.com> <1122042525.10159.77.camel@avon> Date: Fri, 22 Jul 2005 12:11:05 -0400 To: Peter Spreadborough , Suresh Bhaskaran From: Margaret Wasserman Subject: Re: FW: [Rfid] SLRRP Vendor Extensions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org At 10:28 AM -0400 7/22/05, Peter Spreadborough wrote: >Setting the V bit will indicate the presence of the VendorID field in >the message header. If the V bit is not set then the VendorID will not >be present. On receipt of a message with the V bit set an implementation >may decide to accept or reject that message. BTW, once you start having binary fields that are or are not present based on the value of other bits, you lose one of the advantages that David Husak claimed for a binary format -- that you can just put the received buffer in memory and access fields directly without the need to parse anything The "slap it in memory and just access it" plan also runs amok of other issues such as alignment constraints, data packing issues and endianness. All of those can be worked around by proper coding, but it is an implementation consideration whether handling straight binary access will/won't be cheaper (in time, code size or runtime memory use) than parsing the binary data into internal structures upon receipt. If you add variable-length or conditional fields, you'll quickly determine that parsing it once is much more efficient (and less prone to small incompatibility bugs all over your code). Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 14:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2iR-0005wC-DD; Fri, 22 Jul 2005 14:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2iP-0005w4-Ph for rfid@megatron.ietf.org; Fri, 22 Jul 2005 14:57:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10200 for ; Fri, 22 Jul 2005 14:57:43 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw3Ch-0001Nc-4j for rfid@ietf.org; Fri, 22 Jul 2005 15:29:04 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 448953 for rfid@ietf.org; Fri, 22 Jul 2005 14:51:24 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 22 Jul 2005 14:55:02 -0400 To: rfid@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Rfid] Control Plane Architectural Elements X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi All, I made this diagram of what I think the architectural elements should be in the Reader control plane: +----------+ +----------+ | Single | | Multi- | | Reader | | Reader | | App | | App | +----------+ +----------+ +- - - - - - - - -|- - - - - - - |- - - - -+ | Basic | +- - - |- - - - -|- - - - - - + | Reader | | +----V-----+ | Smart | | Controller | | | Multi- | | Reader | | | | | Reader | | Controller | | | | |Controller| | | | | | +----------+ | | | | +- - - |- - - - -|- - - - - - + +- - -|- - - - - - - - -|- - - - - - - |- - - -+ | | | +----V--------------V----+ | | | | | Single | | | | | | Reader | | | | | | Controller | | | | | +------------------------+ | | | +- - - - - - - - - - - - -|- - - - - - - |-+ | +- - - - - - - |- - - - - - - |- - - - - - - + | | +------------V-----------+ | | | | | Low-Level | | | | | | RFID | | | | | | Funcitons | | Basic | |Smart | +------------------------+ | Reader | |Reader +- - - - - - - - - - - - - - -|- - - - - - - + +- - - - - - - - - - - - - - - - - - - - - - - + As you can see, I think that we should separate the control plane into separate multi-reader and single reader control elements, to allow flexibility regarding the "intelligence" level of readers and the corresponding interface for controllers. If I get a chance, I will make a similar diagram for the data plane, where I also beleive that there shold be more than two architectural elements. Thoughts? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 16:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4CN-0003gX-Ul; Fri, 22 Jul 2005 16:32:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4CM-0003Z2-IU for rfid@megatron.ietf.org; Fri, 22 Jul 2005 16:32:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24495 for ; Fri, 22 Jul 2005 16:32:43 -0400 (EDT) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw4ge-0007D8-9Z for rfid@ietf.org; Fri, 22 Jul 2005 17:04:05 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 16:32:17 -0400 Subject: Re: [Rfid] Control Plane Architectural Elements From: Scott Barvick To: Margaret Wasserman In-Reply-To: References: Content-Type: text/plain Message-Id: <1122064335.27520.124.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 22 Jul 2005 16:32:15 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2005 20:32:18.0225 (UTC) FILETIME=[7431CA10:01C58EFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Margaret, Before we start down this path, I think we need to step back and note that we have been working with Bert and the folks at EPCGlobal to make sure that outputs from this group are compatible with the interacting layers of the EPCGlobal Architecture Framework Version 1.0 which can be found at: http://www.epcglobalinc.org/standards_technology/specifications.html The original charter proposal from the SLRRP BoF is quite consistent with the definition of the Reader Protocol (Interface) in Section 9.1.5 of the Architecture Framework. In fact, you'll find concepts from the original SLRRP draft used directly in specifying this interface, and SLRRP appropriately referenced in the References section. I am concerned that starting to work on a general reader architecture would lead us into conflict with the architecture work that is done and published by EPCGlobal. I believe that many of your concerns (autonomous operation, XML interface) are satisfied by the Filtering and Collection (Interface), also known as Application Level Events or ALE, in the EPCGlobal Architecture, and we have never wanted to duplicate this effort with this proposed working group. As you know, ALE is an interface that higher end readers will choose to run, but EPCGlobal also recognizes that there is a need for an interface to readers that is at a lower level in the architecture. Therefore, I think we need to stay more true to the CAIRO proposed charter until the group and/or Bert/IESG decides to change it to take it in a different direction. We have made a lot of progress with the spec and resulting implementations on the reader, RNC, and tools ends of things based on the current charter proposal, and I strongly recommend we stay focused. Thanks, Scott On Fri, 2005-07-22 at 14:55, Margaret Wasserman wrote: > Hi All, > > I made this diagram of what I think the architectural elements should > be in the Reader control plane: > > +----------+ +----------+ > | Single | | Multi- | > | Reader | | Reader | > | App | | App | > +----------+ +----------+ > +- - - - - - - - -|- - - - - - - |- - - - -+ > | Basic | +- - - |- - - - -|- - - - - - + > | Reader | | +----V-----+ | Smart | > | Controller | | | Multi- | | Reader | > | | | | Reader | | Controller | > | | | |Controller| | | > | | | +----------+ | | > | | +- - - |- - - - -|- - - - - - + > +- - -|- - - - - - - - -|- - - - - - - |- - - -+ | > | | +----V--------------V----+ | | > | | | Single | | | > | | | Reader | | | > | | | Controller | | | > | | +------------------------+ | | > | +- - - - - - - - - - - - -|- - - - - - - |-+ > | +- - - - - - - |- - - - - - - |- - - - - - - + > | | +------------V-----------+ | | > | | | Low-Level | | | > | | | RFID | | | > | | | Funcitons | | Basic | > |Smart | +------------------------+ | Reader | > |Reader +- - - - - - - - - - - - - - -|- - - - - - - + > +- - - - - - - - - - - - - - - - - - - - - - - + > > > As you can see, I think that we should separate the control plane > into separate multi-reader and single reader control elements, to > allow flexibility regarding the "intelligence" level of readers and > the corresponding interface for controllers. > > If I get a chance, I will make a similar diagram for the data plane, > where I also beleive that there shold be more than two architectural > elements. > > Thoughts? > > Margaret > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 17:16:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4sD-0006aP-P3; Fri, 22 Jul 2005 17:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4s9-0006Yd-9O for rfid@megatron.ietf.org; Fri, 22 Jul 2005 17:15:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27918 for ; Fri, 22 Jul 2005 17:15:54 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5MR-0000SB-LZ for rfid@ietf.org; Fri, 22 Jul 2005 17:47:17 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449160; Fri, 22 Jul 2005 17:09:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1122064335.27520.124.camel@saco.revasystems.com> References: <1122064335.27520.124.camel@saco.revasystems.com> Date: Fri, 22 Jul 2005 17:15:44 -0400 To: Scott Barvick From: Margaret Wasserman Subject: Re: [Rfid] Control Plane Architectural Elements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Actually the architectural diagram I sent is quite consistent with the EPC Global architecture -- you can view ALE as the multi-reader controller and RP as the single reader controller. Both interfaces might be exposed by a smart reader (for different types of applications/middleware), and so I think that there is a large benefit to having them be consistent (i.e. having them use the same terminology for the same concepts, and the same respresentations for shared data types, etc.) For example, I am not sure how you can claim that the fact that XML is used at a higher-level interface argues _against_ it being used at a lower level. Quite the opposite, I would think. Also, I wonder how we can design a reader control protocol that is consistent with the EPC Global architecture given two important facts: (1) We (the whole IETF community) can't see the current versions of the EPC Global architecture and the protocols that would exist on top, below and beside this protocol, because documents under development in EPC Global are only available to members, and (2) EPC Global already has a effort for every protocol included in their architecture, so we would presumably be developing a suite that is a technical competitor to theirs. Is it your idea that the IETF reader control protocol would be required to plug into the EPC Global architecture in the place of the RP element? Or the RP and RM elements? Or the RP, RM & ALE elements? Your current and future charter items seems to range pretty far outside of RP alone. The last charter I saw is certainly not clear on this point, as it refers to EPC Global as an "air interface standards body", which is about as inaccurate as referring to the IETF as a "layer 3 standards body". >Therefore, I think we need to stay more true to the CAIRO proposed >charter until the group and/or Bert/IESG decides to change it to take it >in a different direction. We have made a lot of progress with the spec >and resulting implementations on the reader, RNC, and tools ends of >things based on the current charter proposal, and I strongly recommend >we stay focused. I am not really sure what this means... Are you saying that discussing whether or not SLRRP is based on the right architectural and technical choices is out-of-scope for this WG and that we are just here to standardize SLRRP more-or-less as-is? This isn't even an IETF WG yet, so being so set on a particular solution at this point doesn't seem reasonable to me. As far as I know, only one vendor was involved in the definition of SLRRP and few (if any) reader vendors have been significantly involved in its evolution. I also have to admit to being somewhat uncomfortable about the fact that someone from Reva is shutting down discussion about whether or not SLRRP is the correct architectural choice, given that this is currently your company's proprietary protocol. Does that seem at all strange to you? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 17:22:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4yp-0001SR-Dn; Fri, 22 Jul 2005 17:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4yo-0001SC-4T for rfid@megatron.ietf.org; Fri, 22 Jul 2005 17:22:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28469 for ; Fri, 22 Jul 2005 17:22:47 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5T7-0000hq-Oo for rfid@ietf.org; Fri, 22 Jul 2005 17:54:10 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449167; Fri, 22 Jul 2005 17:16:40 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1122064335.27520.124.camel@saco.revasystems.com> References: <1122064335.27520.124.camel@saco.revasystems.com> Date: Fri, 22 Jul 2005 17:21:19 -0400 To: Scott Barvick From: Margaret Wasserman Subject: Re: [Rfid] Control Plane Architectural Elements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org At 4:32 PM -0400 7/22/05, Scott Barvick wrote: > I believe that many of your concerns >(autonomous operation, XML interface) are satisfied by the Filtering and >Collection (Interface), also known as Application Level Events or ALE, BTW, the idea that a reader could be told to function autonomously, delivering its data directly to a set of consumers without dependence on a third-party controller is not even touched upon by ALE, since ALE is an interface between higher level applications and middleware. It is true that this interface may be available (at some point in the future) on a smart reader, but I think that this same type of autonomous operation would also be valuable for basic readers that only implement the lower-level reader control protocol (the RP level in the EPC Global architecture). Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Jul 22 23:47:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAyk-0004AH-Ry; Fri, 22 Jul 2005 23:47:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwAyh-00047b-ML for rfid@megatron.ietf.org; Fri, 22 Jul 2005 23:47:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05578 for ; Fri, 22 Jul 2005 23:47:04 -0400 (EDT) Received: from [24.244.171.76] (helo=mail.sarbserve.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwBT0-0005Bc-TX for rfid@ietf.org; Sat, 23 Jul 2005 00:18:30 -0400 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) by mail.sarbserve.com (8.13.4/8.13.4/Debian-3) with ESMTP id j6N3i9e4030139; Fri, 22 Jul 2005 20:44:11 -0700 In-Reply-To: References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [Rfid] XML vs. Text vs. Binary Date: Sat, 23 Jul 2005 09:16:35 +0530 To: Margaret Wasserman X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org margaret - apologies, for not quoting from your email, but i think the issues i raised in my original reply remain untouched, or perhaps are now amplified by your reply. the problem is agreeing on a subset is that we now have to design/ write/debug/use an entirely different set of libraries than the "standard" ones. it takes both hands to count the number of different encoding rules that have been defined/implemented for use with ASN.1 over the years. none of them achieved anywhere near the usage of the original BER, which was the thing that folks were complaining about to begin with. in other words, the compromise becomes more complicated than either purist extreme; it looks like one of those little white lies one tells in polite company that, over the course of the comversation, have to become increasingly more complex so as to avoid discovery through contradiction or non-sequitor. this brings us back full circle: as soon as you have any level of nesting, human type-in becomes problematic. as soon as you decide that human type-in isn't mandatory, it is trivial to include a standard library to do the heavy lifting while the humans invoke the tool using textual commands. in other words, from where i sit, XML, cXML, etc., enjoy all the drawbacks of both purist approaches. /mtr _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Sat Jul 23 08:48:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJQX-0004yw-QF; Sat, 23 Jul 2005 08:48:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJQV-0004x3-BG for rfid@megatron.ietf.org; Sat, 23 Jul 2005 08:48:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22851 for ; Sat, 23 Jul 2005 08:48:20 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwJuv-00041O-OP for rfid@ietf.org; Sat, 23 Jul 2005 09:19:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] Control Plane Architectural Elements Date: Sat, 23 Jul 2005 08:47:52 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF395@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] Control Plane Architectural Elements Thread-Index: AcWPA8Arx/0oWrtwSPGrkRhD+CuQTwAgDXcL From: "P. Krishna" To: "Margaret Wasserman" X-Spam-Score: 0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0051876173==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0051876173== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58F84.BD1A8878" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58F84.BD1A8878 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 > but I think that this same type of > autonomous operation would also be valuable for basic readers that > only implement the lower-level reader control protocol (the RP level > in the EPC Global architecture). > Margaret =20 Pls see ... http://www1.ietf.org/mail-archive/web/rfid/current/msg00197.html = =20 This msg was sent couple of days ago and addresses the same concern = raised in this email. /Krishna ------_=_NextPart_001_01C58F84.BD1A8878 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Rfid] Control Plane Architectural Elements=0A= =0A= =0A=
 
=0A=
> but I think that this same type =0A= of
> autonomous operation would also be = valuable for =0A= basic readers that
> only implement the lower-level reader control =0A= protocol (the RP level
> in the EPC Global =0A= architecture).

> Margaret
=0A=

 

=0A=

Pls see ...

=0A=

http://www1.ietf.org/mail-archive/web/rfid/current/msg00197.html=

=0A=

This msg was sent couple of days ago = and addresses =0A= the same concern raised in this email.

=0A=

/Krishna

=0A= =0A= =0A= ------_=_NextPart_001_01C58F84.BD1A8878-- --===============0051876173== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0051876173==-- From rfid-bounces@lists.ietf.org Sat Jul 23 09:19:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJuG-0006T5-Uj; Sat, 23 Jul 2005 09:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwJuF-0006T0-C3 for rfid@megatron.ietf.org; Sat, 23 Jul 2005 09:19:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24420 for ; Sat, 23 Jul 2005 09:19:05 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwKOh-0004qv-EJ for rfid@ietf.org; Sat, 23 Jul 2005 09:50:35 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449698; Sat, 23 Jul 2005 09:12:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <0E03681B885F3B4296B999E34435A16E01234C2B@ms08.mse3.exchange.ms> Date: Sat, 23 Jul 2005 09:14:45 -0400 To: Marshall Rose From: Margaret Wasserman Subject: Re: [Rfid] XML vs. Text vs. Binary Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi Marshall, I think we are mostly in agreement about the technical trade-offs, but for some reason that doesn't lead us to the same conclusion... At 9:16 AM +0530 7/23/05, Marshall Rose wrote: >this brings us back full circle: as soon as you have any level of >nesting, human type-in becomes problematic. as soon as you decide >that human type-in isn't mandatory, it is trivial to include a >standard library to do the heavy lifting while the humans invoke the >tool using textual commands. Yes, if there is any significant nesting, I agree that a human will not be able to type the commands in from memory and/or by glancing at a reference sheet. However, I don't see any reason why this protocol would require significant nesting, at least for the types of commands that a human is likely to use directly. With a text encoding, a human could also have certain prepared commands and be able to cut and paste them into the interface -- a command to reset autonomous operation, for example, or to set a reader to its default state. Or they could write simple scripts that would send specific commands or command sequences. >in other words, from where i sit, XML, cXML, etc., enjoy all the >drawbacks of both purist approaches. Correct, from a "human typing" standpoint, XML, cXML and a specialized text encoding are all roughly equivalent. However, in my opinion, they are all much better than a binary encoding. There are two factors involved here, and all three of these choices (XML, binary or specialized encodings) are fundamentally different WRT these factors: (1) Can the incoming stream be parsed by a widely available parser, or is a specialized parser necessary. XML parsers are available for all likely client systems, but a specialized text encoding or a binary encoding would require a specialized parser. BTW, subsetting XML _does not_ require a specialized parser. Reader vendors might want to includes a specialized (smaller or faster) parser and simply reject XML constructs that are not included in the subset, but clients could use a regular XML parser for this purpose. (2) Can text processing tools be used to send control messages and interpret the responses, or would binary processing be required. Both XML and a specialized text encoding would allow text processing of the messages and results, while a binary encoding would require binary processing. You've indicated that it is possible, with a binary encoding, for clients to run a tool that gives them text-based access. That's true, but users would need to _get_ that tool from somewhere... So, we are back to requiring specialized code on the client side to access this protocol. This isn't a religious issue with me -- I've just learned the benefits of text-based encoding the hard way, and I don't want to deal with another binary protocol... So, for the moment, we may have to just agree to disagree. We'd obviously need to resolve this before we can move ahead, though. Only a few of us have expressed any opinion on this subject. Are there others out there that have an opinion? There are two questions that I'd especially like to hear answered by specific other people on this list: (1) I'd like to hear from other reader vendors about whether they think that XML would place a prohibitive burden on their readers. It has been asserted that XML would have prohibitive system requirements for the reader. That certainly isn't true of ThingMagic's networked readers. In fact, using a standard parser, like XML, would reduce our development (especially debugging) and testing costs substantially, and would make it more likely that we would implement this protocol. (2) It would be very interesting to know if RFID users would see any benefit to a text-based encoding. Are there folks on this list who have RFID installed in real-world or even pilot installations (not just a few units in a test lab)? Do you have any opinions about whether the ability to access the reader using text-based tools from a client system that doesn't have a specialized client (or library) installed would be useful? Or do you see this as having little/no value? Margaret _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Sat Jul 23 09:33:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK8L-0002zM-Vz; Sat, 23 Jul 2005 09:33:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwK8K-0002zH-E5 for rfid@megatron.ietf.org; Sat, 23 Jul 2005 09:33:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24908 for ; Sat, 23 Jul 2005 09:33:38 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwKcm-0005DK-I0 for rfid@ietf.org; Sat, 23 Jul 2005 10:05:08 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 449704; Sat, 23 Jul 2005 09:27:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <0E03681B885F3B4296B999E34435A16EBFF395@ms08.mse3.exchange.ms> References: <0E03681B885F3B4296B999E34435A16EBFF395@ms08.mse3.exchange.ms> Date: Sat, 23 Jul 2005 09:33:31 -0400 To: "P. Krishna" From: Margaret Wasserman Subject: RE: [Rfid] Control Plane Architectural Elements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi Krishna, Yes, I saw your response earlier. Thanks for reminding me about it. Your response addressed the question of whether the reader can be set to run autonomously without continuous commands sent from the controller to the reader. I didn't remember that SLRRP included this functionality, so it may be time for me to re-read the SLRRP document. I do think that we should define how/if a reader is expected to continue this autonomous operation across a reboot (there are tradeoffs on both sides), but that is a detail, perhaps. There are three other parts of the operational mode that I am discussing that I do not think are captured in SLRRP: (1) I do not believe that the control and data connections should be conflated the way that they are in SLRRP. Even if we decide that a reader can only be controlled by a single controller, it should be possible for a reader to send tag data to more than one consumer and to maintain different filters and different event lists for different consumers. In addition to improving the scaling properties of the system, this would reduce the brittleness of the system (caused by the dependence on a single controller being up at all times). (2) It should not be necessary for a reader to maintain connectivity to the consumer(s) in order for the consumer(s) to see all of the applicable tag reads and events. If connectivity is lost, I believe that readers should cache tag reads and events until the connectivity can be reestablished (or until the cache wraps, of course). (3) I'd also like to see the reader support multiple paradigms for how tag reads and events are sent to consumers, including (at least): the reader and consumer maintain a constant connection over which tag reads and events are transmitted as they occur, the consumer polls the reader periodically for tag reads and events, and the reader actively notifies the consumer when tag reads or events of interest occur (sensor tripped, first tag detected, timeout expired, etc.). After such a notification, the consumer could poll for tag reads, establish a connection to receive tag reads, or do whatever made sense. In fact, it might even make sense to break the data and events out into separate sub-systems and maintain separate concepts of tag data consumers and event consumers. Margaret At 8:47 AM -0400 7/23/05, P. Krishna wrote: > but I think that this same type of > autonomous operation would also be valuable for basic readers that > only implement the lower-level reader control protocol (the RP level > in the EPC Global architecture). > Margaret Pls see ... http://www1.ietf.org/mail-archive/web/rfid/current/msg00197.html This msg was sent couple of days ago and addresses the same concern raised in this email. /Krishna _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Sun Jul 24 14:21:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwl6I-0006tz-8M; Sun, 24 Jul 2005 14:21:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwl6G-0006ts-Go for rfid@megatron.ietf.org; Sun, 24 Jul 2005 14:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12821 for ; Sun, 24 Jul 2005 14:21:18 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwlav-0001UV-9u for rfid@ietf.org; Sun, 24 Jul 2005 14:53:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Rfid] Control Plane Architectural Elements Date: Sun, 24 Jul 2005 14:20:58 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16EBFF39A@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] Control Plane Architectural Elements Thread-Index: AcWPlwRMhZvSgESbTLyWHDNfx6I3hw== From: "P. Krishna" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0117419958==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0117419958== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5907C.701E07B9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5907C.701E07B9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > There are three other parts of the operational mode that I am > discussing that I do not think are captured in SLRRP: > (1) I do not believe that the control and data connections should be > conflated the way that they are in SLRRP. Even if we decide that a > reader can only be controlled by a single controller, it should be > possible for a reader to send tag data to more than one consumer and > to maintain different filters and different event lists for different > consumers. In addition to improving the scaling properties of the > system, this would reduce the brittleness of the system (caused by > the dependence on a single controller being up at all times). > (2) It should not be necessary for a reader to maintain connectivity > to the consumer(s) in order for the consumer(s) to see all of the > applicable tag reads and events. If connectivity is lost, I believe > that readers should cache tag reads and events until the connectivity > can be reestablished (or until the cache wraps, of course). > (3) I'd also like to see the reader support multiple paradigms for > how tag reads and events are sent to consumers, including (at least): > the reader and consumer maintain a constant connection over which tag >reads and events are transmitted as they occur, the consumer polls > the reader periodically for tag reads and events, and the reader >actively notifies the consumer when tag reads or events of interest >occur (sensor tripped, first tag detected, timeout expired, etc.). >After such a notification, the consumer could poll for tag reads, >establish a connection to receive tag reads, or do whatever made >sense. =20 (2) and (3) pertain to the control/config of the rate @ which = tags/events are reported back to the consumer. This is covered in = Section 3.5.6 (specifically 3.5.6.1) of slrrp 02 draft.=20 =20 We have a byte wide field for triggers - we have defined 2 triggers - = one is timeout, the other is every inventory round. =20 Triggers like "sensor tripped, first tag detected, when connected" are = amongst the ones that are going to be added to the trigger definition. = We had some other reader vendors ask for them too. We would like to add = them in 03 version - would you or anybody else be interested in = participating in that effort ? =20 Regarding your concern (1): I think there is a subtle misunderstanding. I'll try to clear it. You = are treating SLRRP as a logical channel between a network of readers = and a network of consumers. In that regards, you are overestimating what = the capability of a "device interface protocol" is. By definition, SLRRP = is a protocol between 2 physical end-points - one RNC (or as you call = it, consumer) and one reader. If you leave it at that, then its up to = the consumer what data events & the rate it subscribes to, and what = configurations/controls it wants to enable at the reader.=20 =20 If there are multiple consumers and 1 reader, and you want all of them = to interact with the reader, then you may have multiple slrrp = connections opened - any conflicts in configuration, operational-setting = is the responsibility at the layer of the network of consumers.=20 =20 In SLRRP, at the command level, we already have built in 2 broadly = different types - one for control (using inventory and access commands), = and one for data (using inventory/access reports commands) - each one = has independent set of parameters. At the slrrp level, you can have one = consumer only sending control commands; another consumer just configure = the reader for the data/event reports. SLRRP doesn't disallow that. It is a reader design issue if it wants to allow for multiple slrrp = connections or not. Likewise it is a design issue at the layer of the = network of consumers to decide for each consumer what path to enable = (control or data or both) to each reader. Once that layer has decided, = then each consumer uses SLRRP to communicate with the reader. Pls see the following for a similar discussion that took place sometime = back on this list ... http://www1.ietf.org/mail-archive/web/rfid/current/msg00112.html =20 Thanks, /Krishna =20 ------_=_NextPart_001_01C5907C.701E07B9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A=
=0A=
> There are three other parts of the = operational =0A= mode that I am
> discussing that I do not think are captured in =0A= SLRRP:
> (1) I do not believe that the control and data = connections should =0A= be
> conflated the way that they are in SLRRP.  Even if we = decide =0A= that a
> reader can only be controlled by a single controller, it = should =0A= be
> possible for a reader to send tag data to more than one = consumer =0A= and
> to maintain different filters and different event lists for =0A= different
> consumers. In addition to improving the scaling = properties of =0A= the
> system, this would reduce the brittleness of the system = (caused =0A= by
> the dependence on a single controller being up at all = times).
> =0A= (2) It should not be necessary for a reader to maintain = connectivity
> to =0A= the consumer(s) in order for the consumer(s) to see all of the
> =0A= applicable tag reads and events.  If connectivity is lost, I =0A= believe
> that readers should cache tag reads and events until the =0A= connectivity
> can be reestablished (or until the cache wraps, of =0A= course).
> (3) I'd also like to see the = reader support =0A= multiple paradigms for
> how tag reads and = events are =0A= sent to consumers, including (at least):
> the reader and consumer =0A= maintain a constant connection over which tag
>reads and events = are =0A= transmitted as they occur, the consumer polls
> the reader = periodically =0A= for tag reads and events, and the reader
>actively notifies the = consumer =0A= when tag reads or events of interest
>occur (sensor tripped, first = tag =0A= detected, timeout expired, etc.).
>After such a notification, the = consumer =0A= could poll for tag reads,
>establish a connection to receive tag = reads, or =0A= do whatever made
>sense.
=0A=

 
=0A=
=0A=
(2) and (3) = pertain =0A= to the control/config of the rate @ which tags/events are = reported =0A= back to the consumer. This is covered in Section 3.5.6 (specifically =0A= 3.5.6.1) of slrrp 02 draft.
=0A=
 
=0A=
We have a = byte wide field =0A= for triggers - we have defined 2 triggers - one is timeout, the =0A= other is every inventory round.
=0A=
 
=0A=
Triggers like "sensor = tripped, =0A= first tag detected, when connected" are amongst the ones that are =0A= going to be added to the trigger = definition. We had some other =0A= reader vendors ask for them too. We would like to add them in = 03 =0A= version - would you or anybody else be interested in participating = in that =0A= effort ?
=0A=
 
=0A=
Regarding your concern = (1):
=0A=
I think there is a subtle = misunderstanding. I'll try to clear it. =0A= You are treating SLRRP as a logical channel between  a network of = readers =0A= and a network of consumers. In that regards, you are overestimating what = the =0A= capability of a "device interface protocol" is. By definition, SLRRP is =0A= a protocol between 2 physical end-points - one RNC  (or as you call =0A= it, consumer) and one reader. If you leave it at that, then its up = to the consumer =0A= what data events & the rate it subscribes to, and what =0A= configurations/controls it wants to enable at the reader.
=0A=
 
=0A=
If there are multiple = consumers and 1 reader, and you want =0A= all of them to interact with the reader, =0A= then you may have multiple slrrp connections opened - any conflicts =0A= in configuration, operational-setting is the responsibility at the = layer of the =0A= network of consumers.
=0A=
 
=0A=
In SLRRP, at the = command level, we already have built =0A= in 2 broadly different types - one for control (using inventory and = access =0A= commands), and one for data (using inventory/access reports commands) - = each one =0A= has independent set of parameters. At the slrrp level, you can have one consumer =0A= only sending control commands; another consumer just configure the = reader for the data/event =0A= reports. SLRRP doesn't disallow that.
=0A=

It is a =0A= reader design issue if it wants to allow for multiple slrrp connections = or not. =0A= Likewise it is a design issue at the layer of the network of =0A= consumers to decide for each consumer what path to enable (control = or data or both) =0A= to each reader. Once that layer has decided, then each consumer = uses SLRRP =0A= to communicate with the reader.

=0A=

Pls see the following for a =0A= similar discussion that took place sometime back on this =0A= list ...

=0A= =0A=
 
=0A=

Thanks,

=0A=
/Krishna
=0A=
 
------_=_NextPart_001_01C5907C.701E07B9-- --===============0117419958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0117419958==-- From rfid-bounces@lists.ietf.org Mon Jul 25 13:19:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6bi-00051o-5E; Mon, 25 Jul 2005 13:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6bg-00050t-FW for rfid@megatron.ietf.org; Mon, 25 Jul 2005 13:19:12 -0400 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08373 for ; Mon, 25 Jul 2005 13:19:09 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 63so672wri for ; Mon, 25 Jul 2005 10:18:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=CzTP5n2n8XgeZTWh7bDRS9x3n2gqjPfFvPeDkO8nHmkC2joqYPzqNLUbBZjuFqYUOdmxWYTceowgacYpQG+g3ezplWfOMt/iDsrW4w7jP1bn3lh2wf3tK2Gt9p46rMjpVekCGRJHjtdr5PSxAZBfR7wQuGybGvrzEnLxCtTsGVg= Received: by 10.54.59.25 with SMTP id h25mr2108wra; Mon, 25 Jul 2005 10:18:40 -0700 (PDT) Received: by 10.54.17.77 with HTTP; Mon, 25 Jul 2005 10:18:40 -0700 (PDT) Message-ID: Date: Mon, 25 Jul 2005 13:18:40 -0400 From: Arjun Roychowdhury To: rfid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [Rfid] Requirements draft for draft-krishna-slrrp-02.txt X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Hi , Just joined this IETF group - I am curious if there is any requirements dra= ft that precedes draft-krishna-slrrp-02.txt ?=20 Is there any draft that describes the requirements of this protocol being developed so that I can better understand the agreed upon motivations before I comment ? There are a lot of questions that come to mind regarding certain choices specified in this draft, and I see some of them have been discussed previously in the archives (including binary vs XML). Others include more discussion on what one means when 'scalability' is a concern : are there any routing / location requirements in the protocol that is needed on the network side (etc etc - the list could go on) Thanks Arjun --=20 Arjun Roychowdhury _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Tue Jul 26 08:07:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxODU-0000y0-K8; Tue, 26 Jul 2005 08:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxODT-0000x2-7T for rfid@megatron.ietf.org; Tue, 26 Jul 2005 08:07:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11220 for ; Tue, 26 Jul 2005 08:07:22 -0400 (EDT) Received: from mse3fe2.mse3.exchange.ms ([69.25.50.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxOiV-0001C5-J4 for rfid@ietf.org; Tue, 26 Jul 2005 08:39:28 -0400 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe2.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 08:06:51 -0400 Subject: Re: [Rfid] Requirements draft for draft-krishna-slrrp-02.txt From: Scott Barvick To: Arjun Roychowdhury In-Reply-To: References: Content-Type: text/plain Message-Id: <1122379610.9886.259.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 26 Jul 2005 08:06:50 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2005 12:06:51.0717 (UTC) FILETIME=[81D6E750:01C591DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Control and Access of Infrastructure for RFID Operations Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Arjun, There is no specific requirements draft that precedes the draft-krishna-slrrp-02.txt. The motivations are outlined in the Introduction section in the draft itself as well as in the draft charter that was first provided for comment for the BoF in March. The most recent version of the draft charter was posted in: http://www1.ietf.org/mail-archive/web/rfid/current/msg00159.html Feel free to refer to either with questions or comments. Scott On Mon, 2005-07-25 at 13:18, Arjun Roychowdhury wrote: > Hi , > Just joined this IETF group - I am curious if there is any requirements draft > that precedes draft-krishna-slrrp-02.txt ? > > Is there any draft that describes the requirements of this protocol > being developed so that I can better understand the agreed upon > motivations before I comment ? > > There are a lot of questions that come to mind regarding certain > choices specified in this draft, and I see some of them have been > discussed previously in the archives (including binary vs XML). Others > include more discussion on what one means when 'scalability' is a > concern : are there any routing / location requirements in the > protocol that is needed on the network side (etc etc - the list could > go on) > > > Thanks > Arjun _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid