Last Modified: 2005-02-09
at IETF 62, Minneapolis, MN
9 March 2005, 13:00-15:00 US/Central
Barvick and Rose, the co-chairs, called the BOF to order. Rose took minutes. Approximately 125 people were in attendance.
Barvick welcomed the group and made an introductory presentation. In brief, the BOF is to explore whether a reader control protocol should be developed for RFID readers. Issues relating to tag/reader RF and high-level APIs are out of scope.
Barvick presented the agenda: a status update, several presentations, followed by an hour of discussion. No bashing of the agenda was suggested.
Barvick presented a status update: a mailing list, email@example.com was created to foster discussion. Further an example draft was written, and revised, to provide a concrete example of the problem space.
P. Krishna presented issues regarding RFID network infrastructure. In brief, end-nodes consist of tags, readers, and controlling applications. A key concern is the density of tags and readers within an environment and the attendant issues of RF interference. The magnitude of readers, and their overlapping responsibilities, suggests a need for ietf-centric expertise with respect to operations, management, and security.
T. Humes presented issues regarding tag management. Tag deployments will be both high-density and mobile. Accordingly, remote configuration to manage RF isolation and tag identification is essential.
K. Powell presented dense-reader issues regarding channelization and tag/reader configuration.
J. Littlefield discussed network management of readers. Configuration is a key concern: as readers should go from power-on to operable without manual interaction; similarly, applications and readers must be able to discover each other easily, and readers must be configured to their necessary "personality" automatically. Once configured, issues of run-time management, fault diagnosis and security arise.
M. Wasserman discussed reader requirements. Readers have a wide footprint range: from traditional end-system capability, to low-end embedded, to handheld systems, to creditcard-sized devices. Accordingly, there are a wide range of options. In terms of configuration and management, SNMP may be appropriate; however, there are many questions relating to level of abstraction, locality of applications, and real-time issues. There are ongoing efforts for reader management, viz., EPCglobal's work on MIBs for reader monitoring, and Web services for reader control.
Resnick asked whether a WG would develop data models. Wasserman replied that hopefully this would be done elsewhere, though others might disagree.
Falstrom asked whether a WG would develop naming and discovery. Wasserman indicated that there had been some success with Rendezvous, but that the larger issued remained.
Rescorla asked what the IETF's value proposition was with respect to this work. Barvick repliced that issues of scalability and performance would be well-served at the IETF. (There was some discussion of protocol specifics at this point, e.g., XML v. frame protocols, TCP v. UDP.) Rose and Rescorla discussed where the line was with respect to IETF interest, e.g., SCSI over IP, DOCSIS, etc. Resnick asked why the RFID people were talking to the IETF. Powell indicated network expertise.
Crawley suggesed that the problem had two parts: getting the data in and out, and management/control/scaling, and that we need to decide whether we're combinging them or not. Powell responded that duplication of the first part wasn't desirable (although real-time issues remain a concern), and that second part wasn't being addressed by EPCglobal.
Resnick wondered whether the problem could be solved by simply writing a MIB. Krishna indicated that SNMP may be insufficient with respect to the control issues.
Crocker observed that the presenters indicated that RFID is growing from small, homogeneous environments to large-scale integrated hetereogeneous ones. That characterization sounds like an IETF problem, actually several IETF-related problems. Krishna agreed.
Shockey thought it would be helpful for the presenters to explain to the audience what work would be parallel, orthogonal, and/or competing with EPCglobal. Barvick presented a "Related Efforts" slide indicating that ISO was working on air protocols and data specifications, but not working on network-centric specifications. In contrast, EPCglobal is working on air protocols and Web services at various levels of the infrastructure. In contrast, SLRRP is intended to focus on network infrastructure requirements of large scale, interoperable deployments across air protocols.
Barvick presented a "WG Proposal" slide outlining a possible charter:
1. Define and document the scope
2. Define the network-side communciations mechanism:
- possibily SLRRP, or something else
- solutions to defined data access and control problems
3. Work on network maturity requirements (post protocol)
- scalable operations (dynamic configuration, service discovery)
- enhanced security
Chandra(?) asked if there were memory/price constraints for readers? Powell indicated that it depends on the specific marketplace; in some markets readers cost $2500, in others they cost $2. Chandra then wondered why XML wasn't scalable. Powell observed is moving away barcodes to tags resulting in an exponential explosion of data.
Shockey asked if the presenters could describe intellectual property issues with respect to RFID. Powell indicated that there was considerable IP with respect to tags, but that there was little IP, to his knowledge, in the network-centric field.
Rescorla, Krishna, and Crocker discussed scalability issues with respect to tags, readers, and applications, observing that a single reader can illuminate 1500 tags/second, with each tag sending 256 bits. With a high-density deployment, congestion may occur between either tags/readers or readers/applications. Crocker observed that this sounds like a networking problem.
Bradner observed that there are networking problems here, but a better description of the problems is needed.
St.Johns thought the work should be done elsewhere as it was reader-centric;l however, if the work introduces codepoints for other kinds of companies, then it would be appropriate for the IETF. Rose asked about the IETF's experience with cable modem management. St.Johns didn't like that example, because he brought that work to the IETF because he couldn't get it done in an industry forum. Rose thought that made for an excellent example.
Eldeeb asked whether the presenters where interested only in the reader/application issues only. Krishna indicated that reader/tag interactions are out of scope.
Shockey thought the work was interesting, but felt that the IETF needed a very narrow scope. Barvick asked whether we should start with the protocol. Shockey did not want to go up the application chain.
Wasserman indicated that the IETF doesn't have the ability to stop the EPCglobal efforts, so there could be multiple overlapping protocols. Krishna noted that none of the reader vendors have implemented EPCglobal's protocol work, which is why the presenters, tag, reader, and network infrastructure vendors, are here at the IETF. Wasserman worried about the maturity of the RFID industry and whether enough was known to do work, and agreed to disagree with Krishna. Crocker shares Wasserman's concerns about parallel efforts, and encourages collaboration.
Lieba observed that standardizing data formats and transmission protocols is what the IETF does.
Shockey, as a participant in both the IETF and EPCglobal efforts, indicated a lack of surprise that RFID folks have come ot the IETF to get work done.
Daigle observed that same-network issues can be addressed outside the IETF; however, if the problem is viewed as a new collection of objects to be managed, then the IETF should be intersted -- fixating on RFID is a distraction.
At this point, the Area Director, Hollenbeck called for a hum on two questions:
1. How many are interested in partipating in this work in the IETF? A noticable humming was evoked.
2. How many are not interested in the IETF pursuing this work? Two hums were heard.
Hollenbeck indicated that the IESG and IAB will review the BOF's interactions and seek additional comment from the community before making a chartering decision.
Finally, Bradner asked wither EPCglobal knew about this effort and whether coordination was necessary. Barvick indicated that the EPCglobal was well aware of the BOF (and that many BOF participants had skipped an EPCglobal concurrent meeting to attend the IETF).
Barvick and Rose adjourned the BOF.