From rfid-bounces@ietf.org Mon Nov 15 21:40:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10054; Mon, 15 Nov 2004 21:40:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTtIR-0000jO-9G; Mon, 15 Nov 2004 21:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtBM-0008BU-33; Mon, 15 Nov 2004 21:35:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTtB3-00086K-VP for rfid@megatron.ietf.org; Mon, 15 Nov 2004 21:34:41 -0500 Received: from sb7.songbird.com (sb7.songbird.com [208.184.79.137]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09785 for ; Mon, 15 Nov 2004 21:34:39 -0500 (EST) Received: from RSHOCKEY-LTXP.shockey.us (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id iAG2Y6vV011149 for ; Mon, 15 Nov 2004 18:34:07 -0800 Message-Id: <6.1.2.0.2.20041115204924.04300320@sb7.songbird.com> X-Sender: richard@sb7.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 15 Nov 2004 20:52:26 -0500 To: rfid@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Rfid] OK ..so would someone explain what this proposed WG is about X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a and why it is not in conflict with EPCglobal efforts in this space..? A. Why should the IETF care? We didnt when they proposed to use the DNS for the ONS. and this is coming BTW from someone who is intimately familiar with EPCglobal and its work. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Wed Nov 17 11:41:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17171; Wed, 17 Nov 2004 11:41:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSuw-0005dJ-CT; Wed, 17 Nov 2004 11:44:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSiK-00019P-2Q; Wed, 17 Nov 2004 11:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUSdX-00086E-9e for rfid@megatron.ietf.org; Wed, 17 Nov 2004 11:26:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15471 for ; Wed, 17 Nov 2004 11:26:24 -0500 (EST) Received: from charles.revasystems.com ([65.209.89.90]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUSfy-00056C-S6 for rfid@ietf.org; Wed, 17 Nov 2004 11:28:59 -0500 Received: from [192.168.1.45] (saco [192.168.1.45]) by charles.revasystems.com (Postfix) with ESMTP id 4366B3BE70 for ; Wed, 17 Nov 2004 11:25:56 -0500 (EST) Subject: re:[Rfid] OK ..so would someone explain what this proposed WG is about From: Scott Barvick To: rfid@ietf.org Content-Type: text/plain; charset=UTF-8 Organization: Reva Systems Corporation Message-Id: <1100708756.2572.43.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 17 Nov 2004 11:25:56 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA15471 X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbarvick@revasystems.com List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Sorry for the delayed response to this question. The archive for this list doesn't appear to be accessible yet, but I'll respond now and repost the question and answer(s) if they don't make it into the archives. This is a good question to kick off the list and have archived for reference.=20 For those who don=E2=80=99t know, EPCGlobal (www.epcglobalinc.org) is an industry consortium of vendors and users that is developing specifications for high level HTTPS/XML/SOAP-based RFID data access services and an RFID air protocol known as =E2=80=98UHF Gen2 Class1=E2=80= =99. It is not the intent of this working group to specify either web services-style access or RFID air protocols. I also put the EPCGlobal ONS in the category of 'high level services' that this working group would not attempt to duplicate. This working group would target reader operations the lower, networking, tag access and control levels which are quite consistent with other operations specified by the IETF. Two main drivers lead us to proposing this working group in the IETF: 1) There are many other RFID air protocol possibilities in use and planned beyond EPCGlobal UHF Gen2 Class1. These include ISO 18006a and 18006b, the first generation Auto-Id air protocols, the 13MHz protocols, and possibly a future air protocol specified by China. With these different protocol possibilities comes the requisite air protocol-specific operations and a need for a single, generic protocol framework in which to execute these operations. 2) The growing requirement to provide for scalable reader deployments supporting large numbers of readers per facility. These readers and the associated infrastructure to support them will need to be good network citizens in these mission-critical networks. To achieve this, this RFID equipment will need to implement best practices and network functions that have been developed for deployments of other network equipment including switches, routers, access points, IP phones, etc, and their associated network management. This is an area that current protocol and operations specifications simply do not address, and this is an area in which the IETF has considerable expertise. When we look at the need for air protocol independence and scalable, network-aware operations, it is clear that the IETF is the proper forum for this type of effort. Other forums will not have a motivation to develop operations for other, possibly competing, air protocols and will obviously not have as close a relationship to the existing standards activities for the networking operations that will be critical for success. I believe that this is enough of a justification to assess the level of interest within the IETF for such work. An initial Internet-Draft has just been published (http://www.ietf.org/internet-drafts/draft-krishna-slrrp-00.txt) that provides a start towards the goal of a full standard RFC. I encourage everyone to read the draft and begin the dialog on this list. In addition, I will post a draft Working Group Charter for discussion that will make clear the goals of this effort and why it is appropriate for the IETF. Scott >> and why it is not in conflict with EPCglobal efforts in this space..? >> >>A. Why should the IETF care? We didnt when they proposed to use the DNS=20 >> for the ONS. >> >>and this is coming BTW from someone who is intimately familiar with=20 >>EPCglobal and its work. --=20 Scott Barvick Reva Systems Corporation (978) 244-0010 x204 _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Wed Nov 17 14:16:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00953; Wed, 17 Nov 2004 14:16:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUVKI-0000ty-5F; Wed, 17 Nov 2004 14:18:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUV97-0002Xb-3m; Wed, 17 Nov 2004 14:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUV5a-0002Dc-2w for rfid@megatron.ietf.org; Wed, 17 Nov 2004 14:03:34 -0500 Received: from charles.revasystems.com (charles.revasystems.com [65.209.89.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29901 for ; Wed, 17 Nov 2004 14:03:32 -0500 (EST) Received: from [192.168.1.45] (saco [192.168.1.45]) by charles.revasystems.com (Postfix) with ESMTP id 596033BE70 for ; Wed, 17 Nov 2004 14:03:03 -0500 (EST) From: Scott Barvick To: rfid@ietf.org Content-Type: multipart/mixed; boundary="=-a86mg8kP790zhvaykcEU" Organization: Reva Systems Corporation Message-Id: <1100718183.2572.96.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 17 Nov 2004 14:03:03 -0500 Subject: [Rfid] Working group charter info strawman X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbarvick@revasystems.com List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c --=-a86mg8kP790zhvaykcEU Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached is a first cut at working group charter information. I created this format by looking at other working group descriptions, so it certainly may be missing things. The point now is more to get the scope and the basic ideas out there and discussed so that we can get a sense of the interest level and key points for discussion and eventual resolution. Thanks, Scott --=-a86mg8kP790zhvaykcEU Content-Disposition: attachment; filename=roma.txt Content-Type: text/plain; name=roma.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Description of Working Group: Radio Frequency Identification (RFID) is a technique whereby a device, known as an RFID 'reader', can remotely sense the presence of, and access embedded memory on, a transponder, known as a 'tag'. Tags may be affixed to objects as a means to track the location and movement of said objects within facilities equipped with readers. Tags may also include environmental sensors that may capture and report conditions to which the tag has been subjected. The tags can be stationary (attached to fixed locations in a facility) or mobile (attached to things moving about the facility). The readers can be stationary (attached to doors, walls, shelving, or scaffolding) or mobile (handheld, or vehicle- mounted). Particular attention has been recently focused on new-generation RFID technology employing low-cost, passive tags operating in worldwide unlicensed UHF spectrum. Early adopters of this technology from a wide variety of industries (including retail, military, healthcare and manufacturing) are very enthusiastic about the potential of RFID to create operational efficiencies, improve productivity, and enhance safety factors, based on the following characteristics of an RFID system: * The ability of readers to single-out individual tags among large aggregations * The ability of readers to read tags rapidly (100s to 1000s per second) * The ability to read tags out of line-of-sight * The ability of the tags to carry unique, serialized object identifiers * The ability of tags to include read/write storage * The applicability of cryptographic technology to secure tag data and system communication Recently, as a result of the development of standard RF (air) protocols and through the application of low-cost embedded computing technology, the implementation of RFID readers has evolved from peripherals, typically connected to a host computer via a serial port; to standalone devices supporting TCP/IP stacks, connected via wired (Ethernet) or wireless (802.11) LAN technology to enterprise computing resources supporting RFID-enabled client applications. This evolution has been accompanied by substantial reader price reductions, as reader manufacturers prepare for large-volume deployments of the technology. For RFID systems to successfully meet client application requirements, high-quality tag scan data must be reliably and economically produced. These systems may require readers deployed in large numbers, and the operation of those readers will need to be effectively coordinated, controlled and managed. 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, embedded software in 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. This working group will specify a controller-to-reader protocol, the Simple Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp') for use in an IP-based network to convey configuration, control, status, and tag information to and from readers. This will be the initial priority of the working group. Subsequently, the working group will specify a set of cooperating functions and possibly protocols that achieve the level of management and operations support expected of devices in today's IP network infrastructure. The full scope of the working group can be summarized as follows: 1) Management of a network of readers: * Discovery * Firmware/software configuration * Health monitoring * Connectivity monitoring * Statistics gathering * Configuration and profile management * Managing reader power consumption * Security 2) RF-domain control: * Allocating RF spectrum utilization across readers * RF monitoring including interference detection and measurement * Reader co-monitoring * Controlling air protocol-specific RF parameters such as backscatter modulation and data rates 3) Air protocol control: * Controlling tag access and tag state across readers * Coordinating singulation parameters and/or state across readers * Distributing reader-generated trigger events It is possible that work undertaken in other working groups and even other standards bodies (e.g. MIBs, discovery protocols) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (e.g. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. ROMA Interaction With Other Standards Bodies: There are currently two organizations that develop specifications for RFID air protocols, ISO and EPCGlobal. Because the IETF will not define a specific RFID air protocol, it is an appropriate venue for the development of an air protocol-independent framework for RFID reader communications and management. This is the goal of SLRRP. Because this working group seeks to develop operations and protocols based on RFID operations defined in publically available documents, there is no need for a formal liason between this working group and other organizations. Members of the working group are encouraged to participate in the other standards development forums so that the proper awareness of dependencies and cooperating functions can be maintained. Goals and Milestones: November 04 Post draft-reva-slrrp-00.txt and draft working group charter February 05 Complete draft charter and determine next phase towards working group chartering for March IETF meeting March 05 Last call on draft-reva-slrrp-0X.txt April 05 Complete required charter actions April 05 Submit SLRRP to IESG as Proposed Standard Internet-Drafts: http://www.ietf.org/internet-drafts/draft-krishna-slrrp-00.txt Informational Links: http://www.iso.org http://www.epcglobalinc.org http://www.rfidjournal.com --=-a86mg8kP790zhvaykcEU Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --=-a86mg8kP790zhvaykcEU-- From rfid-bounces@ietf.org Wed Nov 17 15:43:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10583; Wed, 17 Nov 2004 15:43:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUWh7-0002ue-2O; Wed, 17 Nov 2004 15:46:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWUL-0003NO-T8; Wed, 17 Nov 2004 15:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUWNK-0007pW-4g for rfid@megatron.ietf.org; Wed, 17 Nov 2004 15:25:58 -0500 Received: from rly-ip05.mx.aol.com (rly-ip05.mx.aol.com [64.12.138.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09109 for ; Wed, 17 Nov 2004 15:25:55 -0500 (EST) Received: from smtp-dtc10.proxy.aol.com (smtp-dtc10.proxy.aol.com [205.188.118.97]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN3-4419bb3942e6; Wed, 17 Nov 2004 15:24:52 -0400 Received: from Laptop1 (AC86B959.ipt.aol.com [172.134.185.89]) by smtp-dtc10.proxy.aol.com (8.12.11/8.12.11) with ESMTP id iAHKOTxp025713 for ; Wed, 17 Nov 2004 15:24:30 -0500 Date: Wed, 17 Nov 2004 15:24:44 -0500 From: "Jeffrey Fischer" To: rfid@ietf.org In-Reply-To: Message-ID: <419BB38C.3050501@revasystems.com> References: X-Mailer: AOL Communicator (20030919.3 Win) Organization: Reva Systems MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii X-Scanned-By: MIMEDefang 2.43 X-Apparently-From: ERR_USER_NULL X-AOL-IP: 205.188.118.97 Subject: [Rfid] Re: Rfid Digest, Vol 2, Issue 2 X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jfischer@revasystems.com List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Scott, The response is great. Jeff rfid-request@lists.ietf.org wrote on 11/17/2004, 12:22 PM: _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid