Subject: [Rfid] OK ..so would someone explain what this proposed WG is about

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Nov 2004 20:52:26 -0500

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:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: Scott Barvick <[email-masked]>
Date: Wed, 17 Nov 2004 11:25:56 -0500

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. 

For those who don’t 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 ‘UHF Gen2 Class1’. 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

-- 
Scott Barvick
Reva Systems Corporation
(978) 244-0010 x204