Subject: [Rfid] Where do we go from here?

From: "Eric S. Crawley" <[email-masked]>
Date: Thu, 17 Mar 2005 10:37:18 -0500

At the BoF, there were lots of questions raised but there hasn¹t been much
activity since.  Here¹s my take:

1. We need to define the problem space better.
2. We need to look at design alternatives.
3. We need to determine if the solutions fit into the IETF or elsewhere.

For #1, I think a draft should be written that discusses the real
internetworking problem of the multiple reader environment.  The problem
space can be divided up into two areas: data transport to and from readers
and management/control issues.

For #2, we should look at the two areas of the problem space (transport and
management) and discuss ways this should be handled.  For example, for the
transport problem it has been suggested that XML might work well for
packaging the data to and from the readers.  The SLRRP protocol has been
proposed in this area as well.  What are the tradeoffs?  For the management
problem, can SNMP be used?  What are the issues peculiar to the RFID reader
world that would make this good or bad?  What are the alternatives?

Once we have gone through the first two steps, we can determine if there is
a need for a WG to work out the details of any new stuff required for the
solutions.  It may be that we can package a solution with existing
technology  such that all that is needed is an RFC saying what pieces/parts
to use.

I know there are more questions here than answers but perhaps this is a path
that can move us along.

Thoughts? Comments?  Volunteers?

    Eric

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

---

From: "Nitin H. Vaidya" <[email-masked]>
Date: Thu, 17 Mar 2005 09:44:11 -0600 (CST)

Are the slides from the BoF available? 
I had to miss the BoF due to a conflic with another meeting.
It appears that there were interesting discussions at the BoF, and
I hope to attend the next meeting.

- nitin

-------------------------------------------------------------------------------
Nitin H. Vaidya                              E-mail: [email-masked]
Associate Professor                          Web:    www.crhc.uiuc.edu/wireless
Electrical and Computer Engineering          Phone:  217-265-5414
University of Illinois at Urbana-Champaign   Fax:    217-244-5685

Mailing address: 458 Coordinated Science Laboratory, MC-228 
                 1308 West Main Street
                 Urbana, IL 61801
-------------------------------------------------------------------------------

On Thu, 17 Mar 2005, Eric S. Crawley wrote:

.  >>At the BoF, there were lots of questions raised but there hasn¹t been much
.  >>activity since.  Here¹s my take:
.  >>
.  >>1. We need to define the problem space better.
.  >>2. We need to look at design alternatives.
.  >>3. We need to determine if the solutions fit into the IETF or elsewhere.
.  >>
.  >>For #1, I think a draft should be written that discusses the real
.  >>internetworking problem of the multiple reader environment.  The problem
.  >>space can be divided up into two areas: data transport to and from readers
.  >>and management/control issues.
.  >>
.  >>For #2, we should look at the two areas of the problem space (transport and
.  >>management) and discuss ways this should be handled.  For example, for the
.  >>transport problem it has been suggested that XML might work well for
.  >>packaging the data to and from the readers.  The SLRRP protocol has been
.  >>proposed in this area as well.  What are the tradeoffs?  For the management
.  >>problem, can SNMP be used?  What are the issues peculiar to the RFID reader
.  >>world that would make this good or bad?  What are the alternatives?
.  >>
.  >>Once we have gone through the first two steps, we can determine if there is
.  >>a need for a WG to work out the details of any new stuff required for the
.  >>solutions.  It may be that we can package a solution with existing
.  >>technology  such that all that is needed is an RFC saying what pieces/parts
.  >>to use.
.  >>
.  >>I know there are more questions here than answers but perhaps this is a path
.  >>that can move us along.
.  >>
.  >>Thoughts? Comments?  Volunteers?
.  >>
.  >>    Eric
.  >>
.  >>
.  >>
.  >>_______________________________________________
.  >>Rfid mailing list
.  >>[email-masked]
.  >>https://www1.ietf.org/mailman/listinfo/rfid
.  >>

---

From: Marshall Rose <[email-masked]>
Date: Thu, 17 Mar 2005 16:01:46 -0800

> and management/control issues.

the problem with writing a document in this area, is that it is 
effectively saying that our goal is to have a goal.

it shouldn't take an ietf-style document to do such a thing. i can't 
imagine it taking more than six paragraphs of tightly-written prose, 
and i suspect a disciplined writer could do it in less than 200 words.

i would prefer that people try their hand at writing such a thing in a 
screenful of email and see who comes up with the better goal...

/mtr

---

From: "Eric S. Crawley" <[email-masked]>
Date: Thu, 17 Mar 2005 20:20:16 -0500

Marshall,

I agree that the problem statement could be stated compactly.  I guess I was
thinking of also considering some of the design alternatives.  That would
require more than just a few paragraphs.

    Eric

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Mar 2005 22:54:27 -0800

>  require more than just a few paragraphs.

Sometimes it helps to formulate a statement of what folks want to be able to DO (and do soon) but that they cannot do now.  That is, rather than stating a problem, state a benefit, in very concrete, very operational terms.

In all likelihood, there is a vast pool of such capabilities on people's wish lists -- and everybody has their own list.

So the real challenge is to select a small number that seem likely to be amenable to near-term solution and likely to get a broad base of community support.

By way of providing examples -- but in no way reflecting my believe that they are preferred or practical, since I have not been active with RFID work:

  *  Common set/retrieve reader control methods across different vendors

  *  Inter-device self-coordination protocol, so that readers can be added and removed with potentially overlapping/conflicting signals, and they will self-organize.

  *  Postulate a LAN/WAN kind of meta-model for RFID readers, so that they organize into local "sets" and information from readers in one set can be shared with another.  (For some reason, I am imagining a RFID logistics process that is reminiscent of air traffic control hand-offs from one region to another...)

Leslie Daigle suggested viewing the RFID challenge as representative of a class of similar systems.  I think that is a particularly productive line of attack, essentially defining an application internet, rather than a datagram internet.  That is, a network of networked applications, rather than a network of IP-level networks.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Scott Barvick <[email-masked]>
Date: Fri, 18 Mar 2005 08:36:16 -0500

To reiterate common ground (and generally good advice) from BoF and this
thread is to pick a very specific problem that needs to be solved, get
it in writing, and then start to move forward with it. I'll
second/third/forth that advice and see if we can get the ball rolling on
doing just that.  

I heard two areas of possible focus/problem solving come out in the BoF:
1) Define the standard data access/reader control protocol that meets a
number of specific requirements (i.e. Dave's sample problems to solve)

2) Define the set of management mechanisms for these devices that meets
a number of specific requirements.

I consider the two of these separate and not something we sign up to do
at the same time.  Part of the consideration could be how well one
serves to define the other.

I refrained from listing my views of the requirements for each because I
wanted to see first if there was any discussion on the two paths at the
top level.  I heard some arguments for each as better to be done
first.   Perhaps, the next step is to list the problems that could be
solved by starting with each path or at least the views on how to choose
a path.

Scott

---

From: Scott Barvick <[email-masked]>
Date: Wed, 23 Mar 2005 18:19:46 -0500

Jumping back to this thread to let the good technical work go on about
XML vs. binary debate...

I believe I've seen nobody saying that we should start with the
management side of the problem.  It is real, and it will require real
work, but it can come once we successfully complete the initial
deliverables of the Working Group.

That leaves us with defining the protocol that operates between the
readers and the logically upstream clients/controllers (the official
word should be developed by the working group).   We've had some
specific support for starting this way, and we also have 'spirited'
discussion of one of the base characteristics happening at this time. 
I'll take that to be support for proceeding with the protocol.

Note that we've had a proposal to generalize the effort beyond just
RFID.  I'll assume that it would be consistent to start with the control
protocol in that case as well, and my view is that the pragmatic answer
is using this forum to develop the RFID-based operation in an extensible
way targeting the lowest common denominator platform characteristics.

One step at time.  Can we agree to move forward with protocol as the
base level WG charter item?  The specific problems to be solved in my
view are:
 - supporting reader/upstream-client operations in large scale
deployments of IP-connected readers across the range of expected
platforms
 - supporting coordinated read and access operations for the large
numbers of readers in a facility
 - providing tag data control, access, and inventory capabilities to
support the richness of current air protocols with extensibility
mechanisms to support future air protocol capabilities.

Given the good discussion around the form of the protocol, I would also
expect to document the process that we used to determine the form within
the protocol specification deliverable.

If we can work on suggestions for changes to the charter, we'll be able
to help provide better constraints for the technical issues.

Scott