Subject: [Rfid] A proposal to generalize this work

From: James P Branigan <[email-masked]>
Date: Wed, 23 Mar 2005 17:00:53 -0500

Hi everyone,

I'd like to propose a different starting direction than deciding on a 
binary protocol for RFID Readers.  The proposed approach addresses many of 
the concerns raised at the BOF, while still meeting the core needs 
expressed by the RFID community.  For purposes of clarity, I'll recap my 
impression of the major concerns raised in the BOF and the core needs 
expressed by the presenters.

Major Areas of Concern:

- IETF shouldn't be in the business of creating standards for specific 
domains
- IETF shouldn't tread on the toes of other standards bodies.  In this 
case EPCGlobal.

Core Needs:

- Discovery of RFID Readers
- Remote Firmware/Software Delivery to RFID Readers
- Remote Configuration of RFID Readers
- Remote Management of RFID Readers
- Remote Control of RFID Readers
- Remote Management of RFID Readers
- Security of connection to RFID Readers

I believe that all of the Core Needs expressed here are generalizable to 
an entire class of devices that are starting to be connected to networks 
in great numbers.  In my day to day job as lead embedded developer in 
IBM's Sensors and Actuators Unit, I have come in contact with a wide 
variety of industries that are struggling with the same core issues.  Just 
substitute the words "in-Vehicle computer", "in-home medical monitoring 
station", or "industrial controller" in place of "RFID Readers" in the 
list of Core Needs and you have a very similar problem description.

Medical Devices, Industrial Automation, In Vehicle Systems, each of these 
domains have their own standards bodies, which understand the in-depth, 
domain-specific issues.  These standards bodies do not have the expertise 
that exists in the IETF for network related issues.  Left to their own 
devices, they will either come to the IETF as the RFID Reader community 
has done, or languish on their own, doomed to repeat past mistakes.

I would argue that what is really needed is for IETF to make a "kit", 
which explains how to apply the appropriate existing standards in order to 
meet the Core Needs described above.  This may involve some new work on 
the part of the IETF, but I would see it as primarily a collection and 
consolidation of existing information.  Such a "kit" would provide a great 
service to other standards bodies, such as EPCGlobal.  It would give them 
a great base upon which to build their domain specific standards. 

Using this approach would address both of the main concerns raised at the 
BOF.  The IETF wouldn't be creating standards for specific domains.  The 
IETF also wouldn't be viewed as encroaching on the turf of other standards 
bodies.  I believe this approach would also serve the core needs of the 
RFID community by providing them with a strong base upon which to build a 
standard RFID Reader protocol.

I would appreciate any thoughts on this proposal.

Thanks in advance,

James Branigan

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: Scott Barvick <[email-masked]>
Date: Wed, 23 Mar 2005 17:56:38 -0500

I'll second that I heard this from at least one on other interested
participant at the BoF.  

>From what I've learned in this process, the challenge of this is how to
get chartered for a working group that can solve this problem, but yet
have a specific enough charter that there will be confidence in the
ability to achieve the objectives. 

My pragmatic approach (which I know is less than what you are
suggesting) would be to fold this into an extensibility goal and an even
more 'lowest common denominator' platform expectation requirement across
not just RFID air protocols, but also device types in the protocol. 
After delivering the protocol that would serve as the first success for
the group, a rechartered WG could work on the specific extensions for
different industries.

I'd look to more experienced IETF participants to comment on this from
both the concept and administrative sides.

Scott

On Wed, 2005-03-23 at 17:00, James P Branigan wrote:
> binary protocol for RFID Readers.  The proposed approach addresses
> many of the concerns raised at the BOF, while still meeting the core
> needs expressed by the RFID community.  For purposes of clarity, I'll
> recap my impression of the major concerns raised in the BOF and the
> core needs expressed by the presenters.
> 
> Major Areas of Concern:
> 
> I believe that all of the Core Needs expressed here are generalizable
> to an entire class of devices that are starting to be connected to
> networks in great numbers.  In my day to day job as lead embedded
> developer in IBM's Sensors and Actuators Unit, I have come in contact
> with a wide variety of industries that are struggling with the same
> core issues.  Just substitute the words "in-Vehicle computer",
> "in-home medical monitoring station", or "industrial controller" in
> place of "RFID Readers" in the list of Core Needs and you have a very
> similar problem description.
> 
> Medical Devices, Industrial Automation, In Vehicle Systems, each of
> these domains have their own standards bodies, which understand the
> in-depth, domain-specific issues.  These standards bodies do not have
> the expertise that exists in the IETF for network related issues.
> Left to their own devices, they will either come to the IETF as the
> RFID Reader community has done, or languish on their own, doomed to
> repeat past mistakes.
> 
> which explains how to apply the appropriate existing standards in
> order to meet the Core Needs described above.  This may involve some
> new work on the part of the IETF, but I would see it as primarily a
> collection and consolidation of existing information.  Such a "kit"
> would provide a great service to other standards bodies, such as
> EPCGlobal.  It would give them a great base upon which to build their
> domain specific standards.  
> 
> Using this approach would address both of the main concerns raised at
> the BOF.  The IETF wouldn't be creating standards for specific
> domains.  The IETF also wouldn't be viewed as encroaching on the turf
> of other standards bodies.  I believe this approach would also serve
> the core needs of the RFID community by providing them with a strong
> base upon which to build a standard RFID Reader protocol.
> 
> ______________________________________________________________________

---

From: "Andrew Funk" <[email-masked]>
Date: Thu, 24 Mar 2005 01:27:39 -0700

I want to follow up on the request to generalize the work.  I've seen a lot 
of discussion on binary vs. text, and other more technical topics, but I 
would like to return to the fundamental question of establishing an IETF WG 
charter.  This was the principal focus of the commentary and questions 
portion of the BOF at the last IETF meeting (which I did attend).

I think that if this work is to occur within the IETF,  it needs to be 
relevant and meaningful to the technical and implementation community 
outside of the RFID industry.  Otherwise, EPC Global and ISO efforts could 
easily be extended to address these topics.   I think that it is 
straightforward to demonstrate that there truly are internetworking issues
to be addressed here, and that the IETF community is well suited to tackle 
them.

First, I want to set aside the "RF" side of the reader for a moment.  Those 
protocols are developed by other organizations and we can assume that they 
are in capable hands.  What I want to do instead is focus on the "network" 
side of the RFID reader.  Looking here, I can describe a number of relevant 
attributes of RFID readers and their participation in the enterprise and 
global networks.

+ Readers act as gateways to another communication media, not switches or 
   routers.
   - as pointed out, the RF side characteristics (memory cfg, sensor 
     capability, etc) will affect the nature of control and data piped in 
     and out of the reader.
+ Readers will be a part of existing network infrastructures
   - we need to assume they will be fully integrated
+ Reader deployment needs to be scalable. This means growing one to many.
   - we can argue about how large "many" is in the ongoing effort.
+ As network elements they have very specific characteristics that 
   management and control protocols may not address:
   - readers can be both static and mobile (in the same infrastructure)
   - readers may enter and exit the network (power-saving or event-driven).
   - readers have a broad range of computing capability (from fully capable 
     computing nodes with 100's of MHz, 100's Mbytes of memory to tiny 
     embedded micro-readers)
   - management of readers and the control of their operations may depend 
     heavily on knowledge of the network and the deployment environment, 
     which may not (probably not) exist at a reader (e.g. time slot control)
+ Other elements will need to communicate with readers in an interoperable 
   fashion not only for operations (RFID transactions) but for network 
   relevant activity (addressing, routing, protocol mgmt, spectrum mgmt).
+ As reader networks grow in size and number, the traditional "application-
   to-reader" communication model will shift to more diverse communication 
   models, including hierarchal and mesh models and other layering of data 
   abstraction.

To sum up, I believe that RFID readers represent a very particular class of 
network device with specific internetworking needs.

To echo some of what James posted to the list,  I think the scope (from the 
networking side) is largely about:
 - Management of readers (discovery, configuration, monitoring)
 - Control of readers (security, transaction execution, data transport)

All of these things not only cry out for interoperable standards, but 
standards that are developed leveraging all the work that has gone on 
before, particularly in the IETF.  Simply calling for the use of XML over 
TCP (or http) is not a truly effective re-use and application of experience,

because it doesn't necessarily acknowledge that the reader network has 
unique attributes that may make such a mapping inappropriate and doesn't 
take into account emerging or future models of deployment and use.  At the 
very least, a WG can identify those elements appropriate to IETF scope and 
those that might not be and identify and specify the appropriate mapping to 
the standards.

I'm enthusiastic about an IETF WG that can address the emerging class of 
RFID network devices.  While I like the basic premises of a SLRRP-like 
protocol, I think we have a bit of work to work it into an appropriately 
scoped and detailed specification. 

-Andrew Funk
 Radfly, LLC

---

From: Scott Barvick <[email-masked]>
Date: Thu, 24 Mar 2005 11:37:10 -0500

Andrew,

I am looking for discussion on the scope of the initial WG deliverable
per the post:
http://www1.ietf.org/mail-archive/web/rfid/current/msg00067.html

That proposal specifically targets RFID as the way to start, and more
specifically starts with a protocol that tries to achieve certain
goals.  You are the third person to suggest that there is a problem
here, and perhaps one that should be generalized.  

Do have specific suggestions on 'appropriate' scope, perhaps per the
current proposal?

Scott

---

From: "Andrew Funk" <[email-masked]>
Date: Thu, 24 Mar 2005 10:37:52 -0700

Scott,

Sorry, I should have been clearer.   I do NOT want to over-generalize
the work.  Sticking with the RFID scope to keep this effort focused seems
to be the appropriate path.   When I mentioned "scope and detail", what I
meant was that while defining a control protocol, we need to carefully
segregate network related functionality that will remain common, and RF
related functionality that will change according to air protocols in use,
and have the appropriate encapsulation mechanisms that allow for easy
extension.

I would also like to see the group be more explicit on what represents
"management" functionality that will be dealt with at a later time, because
the current SLRRP draft is peppered with fields and a few commands that
could arguably be construed as management functions.   This isn't a WG
scoping problem, just work that needs to be done by the WG.

My post was just trying to reiterate that there is a problem to be worked on
here.   Between detailed exchanges on the merits of XML and the rabid desire
to coordinate readers (both of which are legitimate sub-topics on this
list),
I didn't want the more general problems of this "new" class of network
device
to be lost.

I think the WG scope as you proposed in your post is a fine starting point.
It addresses control and management, and you propose to focus on the control
protocol with the management functions to be addressed later/separately.
That addresses my concerns.

-Andrew

-----Original Message-----
From: Scott Barvick [mailto:[email-masked]] 
Sent: Thursday, March 24, 2005 9:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Rfid] A proposal to generalize this work

Andrew,

Scott