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

From: "Scott Barvick" <[email-masked]>
Date: Thu, 17 Mar 2005 21:04:06 -0500

The slides will come out in the proceedings, but here they are in advance...
 
Scott

________________________________

From: [email-masked] on behalf of Nitin H. Vaidya
Sent: Thu 3/17/2005 10:44 AM
To: [email-masked]
Subject: Re: [Rfid] Where do we go from here?

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
.  >>

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

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

---

From: Howard Kapustein <[email-masked]>
Date: Fri, 18 Mar 2005 11:28:38 -0500

SLRRP-bof-intro-sbarvick.ppt, slide 9
The 3rd bullet under "EPCglobal" -- "Producing web-service style interface
specifications..." is partially false, and partially factually true but
misleading.
 
EPCglobal has many workgroups designing solutions across a variety of levels
and needs.
Most of these are focusing on web-service style interfaces.
 
The "Reader Protocol" workgroup's next rev (1.0) documents an XML-based
message format but HTTP, TCP and Serial transport mechanisms. Furthermore,
additional (non-XML) message formats *were* planned, but were cut from 1.0
due to time/resource commitments. [Ultimately, not enough folks were
motivated to help work on the non-XML formats at this time considering the
other work involved, personal commitments and so forth.] These non-XML
formats have not been forgotten but you gotta walk before you run, and a
high level of interest assures them key considerations for the next rev of
the spec.
 
I would not consider an ASN.1-based or NDR-based message format over TCP
sockets to be a "web-service style interface". [If it's not SOAP and WSDL,
few people would even if the design patterns are identical.]
 
Other bindings were also considered but ultimately not included in 1.0,
including language bindings, a data services-style paradigm (SQL, XQuery,
etc) and more. I would not consider a COM or CORBA or Java or C# or Python
interface to the Reader Protocol command set to be a "web-service style
interface", and all these (and more) were and are under consideration for
"Reader Protocol" future versions. Again, despite a recurring set of
interest the key priorities focused on 

The "Reader Management" workgroup is defining an SNMP MIB interface for
reader management.
That is very not a "web-service style interface".

So as stated, the "web-services" bullet is the truth, but not the whole
truth.

EPCglobal IP policies limit details that can be shared for emerging
specifications so I can't be more specific.
 
Those of you in our home audience who are members of EPCglobal have access
to more information and are encouraged to inquire with EPCglobal and the
various workgroups if you have specific questions.
 
    - Howard

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Scott Barvick
Sent: Thursday, March 17, 2005 9:04 PM
To: Nitin H. Vaidya; [email-masked]
Subject: RE: [Rfid] Where do we go from here?

Scott

  _____  

- 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
----------------------------------------------------------------------------
---

.  >>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
<https://www1.ietf.org/mailman/listinfo/rfid> 
.  >>

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

---

From: Howard Kapustein <[email-masked]>
Date: Fri, 18 Mar 2005 13:00:26 -0500

Thanks for the clarification
I wan't present so I'm sure there are some things that don't come across
from the ppt, like that

--------------------------
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: P. Krishna <[email-masked]>
To: Howard Kapustein <[email-masked]>
CC: 'Scott Barvick' <[email-masked]>; Nitin H. Vaidya
<[email-masked]>; [email-masked] <[email-masked]>; Kevin Powell
<[email-masked]>
Sent: Fri Mar 18 10:26:11 2005
Subject: RE: [Rfid] Where do we go from here?

Hi Howard,
Kevin in that slide was summarizing his experience with some deployments
which were using a single frequency from a _licensed_ band.

Yes, there are multiple channels available in the unlicensed band. Kevin
I think was presenting some data points for some real-deployments and he
chose to present example of the single freq deployments.

Kevin - do you want to elaborate further on that. 

/Krishna

On Fri, 2005-03-18 at 09:26, Howard Kapustein wrote:
> SLRRP-bof-densereader-kpowell.ppt, Slide 7
> "Currently deployed RFID standard operated in single channel mode"
>  
> Is that accurate?
> There's several currently deployed RFID standards.
> AutoID Center neè EPCglobal have Class 0 and Class 1, plus there's ISO
> 18000-A(?) and -B.
> I thought Class 1 was a multi-channel (multi-frequency?) RF protocol.
>  
> But "I is a software engineer" <g> so it'd be best to verify with a
> hardware guy.
>  
>     - Howard
>  
> 
> ______________________________________________________________________
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Scott Barvick
> ______________________________________________________________________
> ______________________________________________________________________